A hole in the serialization spec

Chris Hegarty chris.hegarty at oracle.com
Mon Feb 10 14:53:59 UTC 2014


David,

" ... undefined in cases where the ObjectInputStream cannot resolve the 
class which defined the writeObject method in question."

I'm not clear as to what this statement is about?

I'm sure you already know this, and maybe in your environment do not 
care much about it, but having a read/writeObject not invoke the 
appropriate default read/write Object/Fields method is a serious 
impediment to evolving the serial form ( in a compatible way ). For 
example, if your class has no serializable fields in one revision, but 
adds a serializable field(s) in a subsequent revision. This could lead 
to a StreamCorruptedException, or some other undefined behavior.

The OpenJDK sources do seem to be quite tolerant of this situation. I'm 
not entirely sure if this is a good or a bad thing. That said, I don't 
think we want to encourage this kind of behavior.

-Chris.

On 07/02/14 15:07, David M. Lloyd wrote:
> 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?
>
> [1]
> http://docs.oracle.com/javase/7/docs/platform/serialization/spec/output.html#861
>
> [2]
> http://docs.oracle.com/javase/7/docs/platform/serialization/spec/input.html#2971
>
>



More information about the core-libs-dev mailing list