A hole in the serialization spec

David M. Lloyd david.lloyd at redhat.com
Fri Feb 7 15:07:39 UTC 2014

Since the topic of serialization has come up recently, I'll take it as 
an excuse to bring up a problem that I've run into a couple of times 
with the serialization specification, which has resulted in user problems.

If you read section 2.3 [1] of the specification, it says:

"The class's writeObject method, if implemented, is responsible for 
saving the state of the class. Either ObjectOutputStream's 
defaultWriteObject or writeFields method must be called once (and only 
once) before writing any optional data that will be needed by the 
corresponding readObject method to restore the state of the object; even 
if no optional data is written, defaultWriteObject or writeFields must 
still be invoked once. If defaultWriteObject or writeFields is not 
invoked once prior to the writing of optional data (if any), then the 
behavior of instance deserialization is undefined in cases where the 
ObjectInputStream cannot resolve the class which defined the writeObject 
method in question."

If you go to section 3.4 [2] of the specification, it reads:

"The readObject method of the class, if implemented, is responsible for 
restoring the state of the class. The values of every field of the 
object whether transient or not, static or not are set to the default 
value for the fields type. Either ObjectInputStream's defaultReadObject 
or readFields method must be called once (and only once) before reading 
any optional data written by the corresponding writeObject method; even 
if no optional data is read, defaultReadObject or readFields must still 
be invoked once."

Now the problem: there are many classes in the wild which nevertheless 
do not write/read fields.  We cause an exception in such cases rather 
than make up some undefined behavior.  What I'm wondering is, is there 
some sensible behavior that could be specified for this case?  The 
Oracle JDK seems to simply leave fields uninitialized in this case, 
maybe that can be a specified behavior?



More information about the core-libs-dev mailing list