What's the purpose of including java.lang.Object in an interface's Constant Pool?

Question

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

Grays

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: #6056624 – Arleta

You can do like MyInterface.equals, or MyInterface.toString – Arleta

@Arleta 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. – Grays

Answer 1

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.

Sternway

I suspect it's a historical wart introduced when retrofitting interfaces into the language, which weren't available in 1.0. – Covington

Thanks! A really interesting comment!! i'm trying to find more information on that. – Sternway

It’s also in line with the statement that the class file representing java/lang/Object is the only class file not having a super_class value. That might make things easier. – Carpentry

Answer 2

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

Merline