Question

Please refer to the Java code below:

class Base{
     Base(){
         System.out.println("Base Constructor");
         method();
     }
     void method(){}    
}

class Derived extends Base{
    int var = 2;
    Derived(){
         System.out.println("Derived Constructor");  
    }

     @Override
     void method(){
        System.out.println("var = "+var);
     }
 }

class Test2{
    public static void main(String[] args) {
        Derived b = new Derived();
    }
}

The output seen is:

Base Constructor
var = 0
Derived Constructor

I think var = 0 occurs because Derived object is half initialized; similar to what Jon Skeet says here

My questions are:

Why does the overridden method get called if the Derived class object isn’t created yet?

At what point in time is var assigned value 0?

Are there any use cases where such behavior is desired?

Answer 1

• The Derived object has been created – it’s just that the constructor hasn’t been run yet. The type of an object never changes in Java after the instant it is created, which happens before all constructors run.

• var is assigned the default value of 0 as part of the process of creating an object, before constructors are run. Basically, the type reference gets set and the rest of the memory representing the object gets wiped to zero (conceptually, anyway – it may already have been wiped to zero before, as part of garbage collection)

• This behaviour at least leads to consistency, but it can be a pain. In terms of consistency, suppose you had a read-only subclass of a mutable base class. The base class may have an isMutable() property which was effectively defaulted to true – but the subclass overrode it to always return false. It would be odd for the object to be mutable before the subclass constructor ran, but immutable afterwards. On the other hand, it’s definitely strange in situations where you end up running code in a class before the constructor for that class has run 🙁

A few guidelines:

• Try not to do much work in a constructor. One way of avoiding this is to do work in a static method, and then make the final part of the static method a constructor call which simply sets fields. Of course, this means you won’t get the benefits of polymorphism while you’re doing the work – but doing so in a constructor call would be dangerous anyway.

• Try very hard to avoid calls to non-final methods during a constructor – it’s very likely to cause confusion. Document any method calls you really have to make very clearly, so that anyone overriding them knows that they will be called before initialization has finished.

• If you have to call a method during construction, it’s usually not then appropriate to call it afterwards. If that’s the case, document it and attempt to indicate it in the name.

• Try not to overuse inheritance in the first place – this is only going to become an issue when you’ve got a subclass deriving from a superclass other than Object 🙂 Designing for inheritance is tricky.