MET04-J. Ensure that constructors do not call overridable methods

According to the Java Language Specification [[JLS 2005]], Section 12.5, "Creation of New Class Instances"

Unlike C++, the Java programming language does not specify altered rules for method dispatch during the creation of a new class instance. If methods are invoked that are overridden in subclasses in the object being initialized, then these overriding methods are used, even before the new object is completely initialized.

This means that a method may use uninitialized data that causes runtime exceptions or leads to unanticipated outcomes. Calling overridable methods from constructors can also result in the escaping of the this reference before construction has concluded. (See guideline TSM01-J. Do not let the (this) reference escape during object construction.)

In addition to constructors, do not call overridable methods from the clone(), readObject() and readObjectNoData() methods as it would allow attackers to obtain partially initialized instances of classes. (See guidelines MET07-J. Do not invoke overridable methods on the clone under construction and SER11-J. Do not invoke overridable methods from the readObject method.) It is also insecure to call an overridden method from the finalize() method. This can prolong the subclass' life and in fact, render the finalization call useless (see the example in guideline MET18-J. Avoid using finalizers.) Additionally, if the subclass's finalizer has terminated key resources, invoking its methods from the superclass may lead one to observe the object in an inconsistent state and in the worst case result in a NullPointerException.

Noncompliant Code Example

This noncompliant code example results in the use of uninitialized data by the doLogic() method.

class SuperClass {
  public SuperClass () {
    doLogic();
  }
	
  public void doLogic() {
    System.out.println("This is super-class!");
  }	
}

class SubClass extends SuperClass {
  private String color = null;
  public SubClass() {
    super();	
    color = "Red";
  }
	
  public void doLogic() {
    // Color becomes null
    System.out.println("This is sub-class! The color is :" + color); 
    // ...
  }
}

public class Overridable {
  public static void main(String[] args) {
    SuperClass bc = new SuperClass(); // Prints "This is super-class!"
    SuperClass sc = new SubClass();  // Prints "This is sub-class! The color is :null"		
  }
}

The doLogic() method is invoked from the superclass's constructor. When the superclass is constructed directly, the doLogic() method in the superclass is invoked without issue. However, when the subclass initiates the super class's construction, the subclasses' doLogic() method is invoked instead. In this case, the value of color is still null because the subclasses constructor has not yet concluded.

Compliant Solution

This compliant solution declares the doLogic() method as final so that it is no longer overridable.

class SuperClass {
  public SuperClass() {
    doLogic();
  }
	
  public final void doLogic() {
    System.out.println("This is super-class!");
  }	
}

Risk Assessment

Allowing a constructor to call overridable methods may give an attacker access to the this reference before an object is fully initialized which, in turn, could lead to a vulnerability.

Automated Detection

TODO

Related Vulnerabilities

Search for vulnerabilities resulting from the violation of this guideline on the CERT website.

Bibliography

[[JLS 2005]] Chapter 8, Classes, 12.5 "Creation of New Class Instances"
[[SCG 2007]] Guideline 4-3 Prevent constructors from calling methods that can be overridden
[[ESA 2005]] Rule 62: Do not call non-final methods from within a constructor.
[[Rogue 2000]] Rule 81: Do not call non-final methods from within a constructor.

      05. Methods (MET)      MET05-J. Do not use overloaded methods to differentiate between runtime types