Virtual tables and abstract in Java

Question

In an interview I was given the following code:

public abstract class Base {
    public int x = 1;
    public Base() {
        foo();
    }
    public abstract v         


        

Answer 1

Obviously, only the derived class's foo() is called.

It prints 0 in the first time because it happens before assigning x = 2, which happens only in the constructor of Derived, after Base's initialization is complete. It prints 0 and not 1, because Derived.x is being accessed and not Base.x, and it was not initialized yet, and is still 0. The declaration of x in Derived hides the field in Base, so when Derived is printing x, it prints Derived.x.

EDIT: activation order when creating Derived(): [schematic]

1. create Base:
   1.1. assign Base.x = 1
   1.2. invoke foo()
      1.2.1 print Derived: Derived.x //Derived.x was not initialized here yet!
2. assign Derived.x = 2

The second is trivial and expected [in my opinion at least].

Answer 2

This is the order in which the code is executed. More details follow.

• main()
  • invokes Derived.<init>() (the implicit nullary constructor)
    • invokes Base.<init>()
      • sets Base.x to 1.
      • invokes Derived.foo()
        • prints Derived.x, which still has the default value of 0
    • sets Derived.x to 2.
  • invokes Derived.foo().
    • prints Derived.x, which is now 2.

---

To completely understand what is going on, there are several things you need to know.

Field Shadowing

Base's x and Derived's x are completely different fields which happen to have the same name. Derived.foo prints Derived.x, not Base.x, since the latter is "shadowed" by the former.

Implicit Constructors

Since Derived has no explicit constructor, the compiler generates an implicit zero-argument constructor. In Java, every constructor must call one superclass constructor (with the exception of Object, which has no superclass), which gives the superclass a chance to safely initialize its fields. A compiler-generated nullary constructor simply calls the nullary constructor of its superclass. (If the superclass has no nullary constructor, a compilation error is produced.)

So, Derived's implicit constructor looks like

public Derived() {
    super();
}

Initializer Blocks and Field Definitions

Initializer blocks are combined in declaration order to form a big block of code which is inserted into all constructors. Specifically, it is inserted after the super() call but before the rest of the constructor. Initial value assignments in field definitions are treated just like initializer blocks.

So if we have

class Test {
    {x=1;}
    int x = 2;
    {x=3;}

    Test() {
        x = 0;
    }
}

This is equivalent to

class Test {
    int x;

    {
        x = 1;
        x = 2;
        x = 3;
    }

    Test() {
        x = 0;
    }
}

And this is what the compiled constructor will actually look like:

Test() {
    // implicit call to the superclass constructor, Object.<init>()
    super();
    // initializer blocks, in declaration order
    x = 1
    x = 2
    x = 3
    // the explicit constructor code
    x = 0
}

Now let's return to Base and Derived. If we decompiled their constructors, we would see something like

public Base() {
    super(); // Object.<init>()
    x = 1; // assigns Base.x
    foo();
}

public Derived() {
    super(); // Base.<init>()
    x = 2; // assigns Derived.x
}

Virtual Invocations

In Java, invocations of instance methods normally go through virtual method tables. (There are exceptions to this. Constructors, private methods, final methods, and methods of final classes cannot be overridden, so these methods can be invoked without going through a vtable. And super calls do not go through vtables, since they are inherently not polymorphic.)

Every object holds a pointer to a class handle, which contains a vtable. This pointer is set as soon as the object is allocated (with NEW) and before any constructors are called. So in Java, it is safe for constructors to make virtual method calls, and they will be properly directed to the target's implementation of the virtual method.

So when Base's constructor calls foo(), it invokes Derived.foo, which prints Derived.x. But Derived.x hasn't been assigned yet, so the default value of 0 is read and printed.