How does Java force classes to extend Object?

Question

How does this happen internally? What mechanism is used? JNI, reflection or something different? Does the compiler include the extends clause, perhaps?

Answer 1

Not completely correct.

All classes extend Object if they don't already extend another class, with one exception: java.lang.Object itself doesn't extend any class.

The compiler embeds the superclass java.lang.Object in the class file if the code doesn't specify another superclass.

You can even see it yourself if you open the .class file with your favorite editor, you can see the string java/lang/Object embedded in binary data.

(You can compile a very simple source file like public class A { } to observe this best)

Answer 2

This is an interesting question about the internals of the java compiler. I found a list of docs providing a high level view of javac [1][2][3][4]. Source code for a specific implementation like OpenJdk can be found online too [source].

Compilation consists of 3 high level steps [5]:

1. "parse and enter"
2. "annotation processing"
3. "analyse and generate"

I wrote some code to test these steps out using the Compiler Tree API which provides an interface to javac.

static class TestFileObject extends SimpleJavaFileObject {
    public TestFileObject() {
        super(URI.create("Test.java"), JavaFileObject.Kind.SOURCE);
    }
    public CharSequence getCharContent(boolean ignoreEncodingErrors) {
        return "class Test { private int x; }";
    }
}

public static void main(String[] args) throws IOException {
    JavacTool tool = JavacTool.create();
    JavacTask task = tool.getTask(null, null, null, null, null,
            com.sun.tools.javac.util.List.of(new TestFileObject()));

    // Step 1, Parse
    Iterator<? extends CompilationUnitTree> trees = task.parse().iterator();

    // Step 3, Analyze
    // Iterator<? extends Element> elements = task.analyze().iterator();

    // Step 3, Generate
    // Iterator<? extends JavaFileObject> files = task.generate().iterator();

    while(trees.hasNext()) {
        CompilationUnitTree cu = trees.next();
        System.out.println(cu.getTypeDecls());
    }
}

Running the above code with Step 1 shows the following output:

class Test {
    private int x;
}

So the AST doesn't contain references to java.lang.Object. Next, I uncommented "Step 3, Analyse" and re-ran my code with the resulting output:

class Test {

    Test() {
        super();
    }
    private int x;
}

Notice that the Test() constructor and super() was added in this step, which also corresponds to the explanation for Step 3 [5] :

While analysing the tree, references may be found to classes which are required for successful compilation, but which were not explicitly specified for compilation.

Finally, I uncommented Step 3, Generate, which creates the Test.class file. Calling javap -c Test.class, the resulting bytecode is blelow :

class Test {
  Test();
    Code:
       0: aload_0
       1: invokespecial #1                  // Method java/lang/Object."<init>":()V
       4: return
}

So my conclusion is that the bytecode generation step adds the java.lang.Object related logic.