13

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:

JBE screenshot

Note: Using jdk1.7.0_75

M A
  • 65,721
  • 13
  • 123
  • 159
  • 1
    Well I would say that is because, the interface (even that it does not inherit from object by looking at the documentation) bytecode does this beacause Interfaces declare all the methods from Object. Check this out, there is some cool explanation: http://stackoverflow.com/questions/6056124/do-interfaces-inherit-from-object-class-in-java – maslan Jun 01 '15 at 14:23
  • 1
    You can do like MyInterface.equals, or MyInterface.toString – maslan Jun 01 '15 at 14:24
  • @maslan That's one of the reasons I thought of. But if `java.lang.Object` is explicitly in the bytecode, then I was wondering why these implicit methods are not there as well. I think it's close to this reason but more about what the below answers and comments describe. – M A Jun 01 '15 at 16:39

2 Answers2

9

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 class Object.

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 class Object, the only class or interface without a direct superclass.

Umberto Raimondi
  • 16,269
  • 7
  • 44
  • 54
1

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

Sergey Shustikov
  • 13,329
  • 9
  • 57
  • 110