SER11-J. Do not invoke overridable methods from the readObject method

Invoking overridable methods from the readObject() method can allow the overriding method to read the state of the subclass before it is fully constructed, since the base class is deserialized first, followed by the subclass. Therefore readObject() must not call any overridable methods.

Also see the related guideline MET07-J. Do not invoke overridable methods in clone().

Noncompliant Code Example

This noncompliant code example invokes an overridable method from the readObject() method.

private void readObject(final ObjectInputStream stream) throws 
    IOException, ClassNotFoundException {
  overridableMethod(); 
  stream.defaultReadObject();
}

public void overridableMethod() {
  // ...
}

Compliant Solution

This compliant solution removes the call to the overridable method. When removing such calls is infeasible, ensure that the overridable method is declared private or final.

private void readObject(final ObjectInputStream stream) throws 
    IOException, ClassNotFoundException {
  stream.defaultReadObject();
}

Exceptions

SER11-EX1: "The readObject methods will often call java.io.ObjectInputStream.defaultReadObject, which is an overridable method" [[SCG 2009]]. Such calls are permitted.

Risk Assessment

Invoking overridable methods from the readObject() method can lead to initialization errors.

Related Vulnerabilities

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

Bibliography

[[API 2006]]
[[SCG 2009]] Guideline 4-4 Prevent constructors from calling methods that can be overridden
[[Bloch 2008]] Item 17: "Design and document for inheritance or else prohibit it"

VOID SER10-J. Do not serialize direct handles to system resources      16. Serialization (SER)      SER12-J. Avoid memory and resource leaks during serialization