Page History

...

It is possible to add access-specifier to the readResolve() and writeReplace() methods. However, if they are declared private, extending classes cannot invoke or override them. Similarly, if either of these methods is declared static, extending classes cannot override the method, they can only hide it.

Deviating from these method signatures produces a method that is not invoked during object serialization or deserialization. Such methods, especially if declared public, might be accessible to untrusted code.

Unlike most interfaces, Serializable does not define the method signatures it requires because readObject() and writeObject() are private. Consequently, the Java compiler will not identify an incorrect method signature.

...

This noncompliant code example shows a class Ser with a private constructor, indicating that code external to the class should not be able to create instances of it. The class implements java.io.Serializable and defines public readObject() and writeObject() methods. Consequently, untrusted code can obtain the reconstituted objects by using readObject(), and can write to the stream by using writeObject().

...

This compliant solution declares the readObject() and writeObject() methods private and non-static to limit their accessibility.

...

This noncompliant code example declares the readResolve() and writeReplace() methods as private.

class Extendable implements Serializable {
  private Object readResolve() {
    // ...
  }

  private Object writeReplace() {
    // ...
  }
}

...

This noncompliant code example declares the readResolve() and writeReplace() methods as static.

class Extendable implements Serializable {
  protected static Object readResolve() {
    // ...
  }

  protected static Object writeReplace() {
    // ...
  }
}

...

This compliant solution declares the two methods protected while eliminating the static keyword, so that subclasses can inherit them.

...

Related Guidelines

...

...