JDK-7019074 : -Xlint serial flag could perform correctness checks on readObject/writeObject
  • Type: Enhancement
  • Component: tools
  • Sub-Component: javac
  • Affected Version: 7
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • OS: generic
  • CPU: generic
  • Submitted: 2011-02-11
  • Updated: 2021-10-08
Related Reports
Relates :  
JDK-8160675 - Issue lint warning for non-serializable non-transient instance fields in serializable type
Relates :  
JDK-8202056 - Expand serial warning to check for bad overloads of serial-related methods and ineffectual fields
Description
The serialization specification defines several correctness properties of readObject and and writeObject methods.  For example, for writeObject "Either ObjectOutputStream's defaultWriteObject or writeFields method must be called once (and only once)..." [1]

The -Xlint:serial checking of javac could be expanded to analyze the bodies of serialization methods for these properties.

[1] http://download.oracle.com/javase/6/docs/platform/serialization/spec/output.html#861
Comments
There are some additional checks on the serialization methods that could be performed. For example: * readObject/writeObject should exist as a pair (but see below) * readResolve/writeReplace should exist as a pair (but see below) * if there is a readObject, there should also be a readObjectNoData method. There are some special circumstances about this though, e.g. it's unnecessary to have ROND if the class isn't subclassable. [~jboes] has done some work in this area. The checking of readObject to ensure that it calls either defaultReadObject or readFields (and similar for writeObject), as suggested in the description, requires looking into the parse tree of the method implementation. Some of the additional checks mentioned above might be possible using only information in the declarations, in which case they could be split into another JIRA issue. However, there are enough special cases with them that they might benefit from an analysis of the parse tree. Another consideration for some of these methods is the serialization proxy pattern. An object using the pattern typically has a readObject method but no writeObject method, and a writeReplace but no readResolve method. There are similar asymmetries in the proxy object. The checking for the serialization proxy pattern is sufficiently different that we might not want to build it into javac, in which case this should be moved into a separate JIRA issue.
08-10-2021