Compiling the following interface:
package test;
public interface MyInterface {
public void foo();
}
and checking the compiled code using javap -v -s test.MyInterface
shows the following (-s
prints member signatures):
Compiled from "MyInterface.java"
public interface test.MyInterface
SourceFile: "MyInterface.java"
minor version: 0
major version: 51
flags: ACC_PUBLIC, ACC_INTERFACE, ACC_ABSTRACT
Constant pool:
#1 = Class #7 // test/MyInterface
#2 = Class #8 // java/lang/Object
#3 = Utf8 foo
#4 = Utf8 ()V
#5 = Utf8 SourceFile
#6 = Utf8 MyInterface.java
#7 = Utf8 test/MyInterface
#8 = Utf8 java/lang/Object
{
public abstract void foo();
Signature: ()V
flags: ACC_PUBLIC, ACC_ABSTRACT
}
My question is: Why is there java.lang.Object
in the constant pool, knowing that an interface does not inherit from the Object
class?
Also if I change the interface definition to:
public interface MyInterface extends Comparable<MyInterface> {
public void foo();
}
and run javap
, I get the following:
Compiled from "MyInterface.java"
public interface test.MyInterface extends java.lang.Comparable<test.MyInterface>
Signature: #7 // Ljava/lang/Object;Ljava/lang/Comparable<Ltest/MyInterface;>;
SourceFile: "MyInterface.java"
minor version: 0
major version: 51
flags: ACC_PUBLIC, ACC_INTERFACE, ACC_ABSTRACT
...
What exactly is the purpose of including java.lang.Object
in the signature Ljava/lang/Object;Ljava/lang/Comparable<Ltest/MyInterface;>;
of the interface?
Also, if I try to view the bytecode using a tool (specifically JBE), it incorrectly shows that MyInterface
has java.lang.Object
as superclass with the class name java.lang.Object
saved in the constant pool:
Note: Using jdk1.7.0_75
Constant Pool in Java. Simply put, a constant pool contains the constants that are needed to run the code of a specific class. Basically, it's a runtime data structure similar to the symbol table. It is a per-class or per-interface runtime representation in a Java class file.
The runtime constant pool is an implementation-specific data structure that maps to the constant pool in the class file. Thus, after a type is initially loaded, all the symbolic references from the type reside in the type's runtime constant pool.
That Object
class reference in the Constant Pool is the result of how the class file format has been defined in the Java VM Specification.
A class file consists of a single ClassFile structure:
ClassFile {
u4 magic; // The Famous 0xCAFEBABE
u2 minor_version;
u2 major_version;
u2 constant_pool_count;
cp_info constant_pool[constant_pool_count-1];
u2 access_flags;
u2 this_class;
u2 super_class;
...
}
Regarding that super_class
, this section of the JVM Specification is relevant for your MyInterface
interface:
super_class
For an interface, the value of the super_class item must always be a valid index into the constant_pool table. The constant_pool entry at that index must be a
CONSTANT_Class_info
structure representing the classObject
.
So essentially, that java/lang/Object
constant is needed only to fill the super_class
item with a valid value.
All Java instances are always instance of the basic Object
class but this time the real answer has more to do with how the JVM was built and with specific implementation choices rather than with the language itself.
Also, as noted by @Holger, this paragraph is also worth mentioning:
If the value of the
super_class
item is zero, then this class file must represent the classObject
, the only class or interface without a direct superclass.
Actually all in Java is Object
. In Java each construction is object.
Class IS Object
Interface IS Object
Enum IS Object.
So when you build program Object
packed automatically. Because *.class
may be used on another JVM.
@user43250937 correctly in this case too.
JVM Spec :
Compiled code to be executed by the Java Virtual Machine is represented using a hardware- and operating system-independent binary format, typically (but not necessarily) stored in a file, known as the class file format. The class file format precisely defines the representation of a class or interface, including details such as byte ordering that might be taken for granted in a platform-specific object file format
May be this link granted to your more informations.
Java-bytecode-fundamentals-using-objects-and-calling-methods
Look at
4: invokeinterface #5, 1; //InterfaceMethod Job.execute:()Ljava/lang/Object;
JVM Specification
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With