According to the The Java Language Specification \[[JLS 2005|AA. Bibliography#JLS 05]\], section 12.5 "Creation of New Class Instances", §12.5, "Creation of New Class Instances" [JLS 2015]: Wiki Markup
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 and cause Invocation of an overridable method during object construction may result in the use of uninitialized data, leading to runtime exceptions or lead to unanticipated outcomes. Calling overridable methods from constructors can also result in leak the escaping of the this
reference before construction has concluded object construction is complete, potentially exposing uninitialized or inconsistent data to other threads (see TSM01-J. Do not let the ( this ) reference escape during object constructionfor additional information). As a result, a class's constructor must invoke (directly or indirectly) only methods in that class that are static, final or private.
Noncompliant Code Example
This noncompliant code example invokes the doLogic()
method from the class constructor. The superclass's doLogic()
method gets invoked on the first call, however, the overriding method is invoked on the second one. In the second call, the issue is that the constructor for SubClass
initiates the super class's constructor which undesirably ends up calling SubClass
's doLogic()
method. The value of color
is left as null
because the initialization of the class SubClass
has not yet concluded. results in the use of uninitialized data by the doLogic()
method:
Code Block | ||
---|---|---|
| ||
class BaseClassSuperClass { public BaseClassSuperClass () { doLogic(); } public void doLogic() { System.out.println("This is super-classsuperclass!"); } } class SubClass extends BaseClassSuperClass { private String color = null; public SubClass() { super(); color = "Red"; } "red"; public void doLogic() { // Color becomes null System.out.println("This is sub-classsubclass! The color is :" + color); // ... } } public class Overridable { public static void main(String[] args) { BaseClassSuperClass bc = new BaseClassSuperClass(); // Prints "This is super-classsuperclass!" BaseClassSuperClass sc = new SubClass(); // Prints "This is sub-classsubclass! 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 superclass's construction, the subclass's doLogic()
method is invoked instead. In this case, the value of color
is still null
because the subclass's constructor has not yet concluded.
Compliant Solution
This compliant solution declares the doLogic()
method as final so that it is no longer overridable.cannot be overridden:
Code Block | ||
---|---|---|
| ||
class BaseClassSuperClass { public BaseClassSuperClass() { doLogic(); } public final void doLogic() { System.out.println("This is super-classsuperclass!"); } } |
...
Risk Assessment
Allowing a constructor to call overridable methods may give can provide an attacker with access to the this
reference before an object is fully initialized, which , in turn, could lead to a vulnerability.
Rule | Severity | Likelihood | Remediation Cost | Priority | Level |
---|
MET05-J |
Medium |
Probable |
Medium | P8 | L2 |
Automated Detection
TODO
Related Vulnerabilities
Search for vulnerabilities resulting from the violation of this rule on the CERT website.
References
Wiki Markup |
---|
\[[JLS 2005|AA. Bibliography#JLS 05]\] [Chapter 8, Classes|http://java.sun.com/docs/books/jls/third_edition/html/classes.html], 12.5 "Creation of New Class Instances"
\[[SCG 2007|AA. Bibliography#SCG 07]\] Guideline 4-3 Prevent constructors from calling methods that can be overridden
\[[ESA 2005|AA. Bibliography#ESA 05]\] Rule 62: Do not call non-final methods from within a constructor. |
Automated detection of constructors that contain invocations of overridable methods is straightforward.
Tool | Version | Checker | Description | ||||||
---|---|---|---|---|---|---|---|---|---|
PVS-Studio |
| V6052 | |||||||
SonarQube |
| S1699 | Constructors should only call non-overridable methods | ||||||
SpotBugs |
| MC_OVERRIDABLE_METHOD_CALL_IN_CONSTRUCTOR | Implemented (since 4.5.0) |
Related Guidelines
Inheritance [RIP] | |
Guideline 7-4 / OBJECT-4: Prevent constructors from calling methods that can be overridden |
Bibliography
[ESA 2005] | Rule 62, Do not call nonfinal methods from within a constructor |
[JLS 2015] | Chapter 8, "Classes" |
Rule 81, Do not call non-final methods from within a constructor |
...
16. Methods (MET) MET05-J. Do not subject overloaded methods to polymorphic invocations