A hole in the serialization spec

[Chris Hegarty]

David, others?

I'm afraid I'm still not clear what is mean by:
   " ... undefined in cases where the ObjectInputStream cannot resolve
     the class which defined the writeObject method in question."

This does not seem directly related to the issue we are discussing ( 
whether to invoke default read/write object ).

-Chris.

On 10/02/14 15:37, David M. Lloyd wrote:
> I agree that it's a problem; however it's also clear that there are many
> classes in the wild which have this problem.  It would be nice if the
> behavior could _become_ defined *somehow* though.  I can see at least
> four options:
>
> 1) do nothing :(
> 2) start throwing (or writing) an exception in write/readObject when
> stream ops are performed without reading fields (maybe can be disabled
> with a sys prop or something)
> 3) leave fields cleared and risk protocol issues
> 4) silently start reading/writing empty field information (risks
> protocol issues)
>
> Maybe there are better options I'm not thinking of.
>
> On 02/10/2014 08:53 AM, Chris Hegarty wrote:
>> 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
>>>
>>>
>>>
>>>
>
>