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.
Consequently, invocation of an overridable method during object construction may result in the use of uninitialized data, leading to runtime exceptions or to unanticipated outcomes. Calling overridable methods from constructors can also leak the this
reference before object construction is complete, potentially exposing uninitialized or inconsistent data to other threads. See guideline TSM01-J. Do not let the (this) reference escape during object construction for additional information. As a result, constructors may invoke only methods that are final or private; all other method invocations are forbidden.
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 and executes successfully. However, when the subclass initiates the super class's construction, the subclass' doLogic()
method is invoked instead. In this case, the value of color
is still null
because the subclass' constructor has not yet concluded.
Compliant Solution
This compliant solution declares the doLogic()
method as final
so that it cannot be overridden.
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.
Guideline |
Severity |
Likelihood |
Remediation Cost |
Priority |
Level |
---|---|---|---|---|---|
MET04-J |
medium |
probable |
medium |
P8 |
L2 |
Automated Detection
Automated detection of constructors that contain invocations of overridable methods appears to be straight forward.
Related Vulnerabilities
Search for vulnerabilities resulting from the violation of this guideline on the CERT website.
Bibliography
[[ESA 2005]] Rule 62: Do not call non-final methods from within a constructor.
[[JLS 2005]] Chapter 8, Classes, 12.5 "Creation of New Class Instances"
[[Rogue 2000]] Rule 81: Do not call non-final methods from within a constructor.
[[SCG 2007]] Guideline 4-3 Prevent constructors from calling methods that can be overridden
05. Methods (MET) MET07-J. Do not invoke overridable methods in clone()