A hole in the serialization spec

[David M. Lloyd]

Interestingly, if the behavior in this case was to write empty values on 
the write side and read and discard on the read side, both the behavior 
and the serialized format of java.util.Date would be identical to today; 
though other pathological classes might be incompatible, they were 
already in undefined-land.

On 02/14/2014 12:01 PM, David M. Lloyd wrote:
> Yes, however given that the lack of reading/writing fields makes it
> undefined *in general*, you can only say "the behavior is defined as
> long as this undefined behavior is actually defined in this (risky)
> manner".
>
> Put another way, since the behavior of not reading/writing fields is not
> defined, this class is then by spec not portable between JVMs (after
> all, undefined behavior could mean anything at all).  That's why I was
> saying that the spec should define exactly what will physically happen
> if you do this (from both the perspective of the "other end" of the
> serialization API, *and* the wire protocol), even if it's considered
> poor practice - because then at least you have guaranteed
> interoperability (which becomes even more important with the knowledge
> that JDK classes have this issue).
>
> On 02/14/2014 10:31 AM, roger riggs wrote:
>> Hi David,
>>
>> I would quibble that the serialized form of java.util.Date is defined.
>> The behavior is defined by the writeObject and readObject methods.
>> They write and read a time computed from and restored to the state of
>> the object.
>>
>> Roger
>>
>> On 2/14/2014 10:56 AM, David M. Lloyd wrote:
>>> On 02/13/2014 11:38 AM, David M. Lloyd wrote:
>>>> On 02/13/2014 10:29 AM, Chris Hegarty wrote:
>>>>> On 12 Feb 2014, at 15:24, David M. Lloyd <david.lloyd at redhat.com>
>>>>> wrote:
>>>>>
>>>>>> That's a quote from the serialization spec.  I take it to mean,
>>>>>> "Don't write fields and everything might go to hell".  In practice,
>>>>>> if the reading side doesn't read fields, things end up more or less
>>>>>> OK, as evidenced by various classes in the wild.  But it's not hard
>>>>>> to imagine a scenario in which a class change could cause protocol
>>>>>> corruption.
>>>>>>
>>>>>> I think the specifics of the quote relate to this kind of class
>>>>>> change; in particular, if a class is deleted from the hierarchy on
>>>>>> the read side, and that class corresponds to the class that had the
>>>>>> misbehaving writeObject, I suspect that things will break at that
>>>>>> point as the read side will probably try to consume and discard the
>>>>>> field information for that class, which will be missing (it will
>>>>>> start reading the next class' fields instead I think).
>>>>>
>>>>> Yes, possibly. And who knows what fields/values may be read and
>>>>> mistaken for the wrong object in the hierarchy. So ‘undefined'
>>>>> behaviour seems right to me.
>>>>
>>>> I think the behavior is well-defined, just "bad", which is my
>>>> point.  If
>>>> the exact current is spec'd out as-is then at least we can be
>>>> assured of
>>>> the same bad behavior across implementations.  If the behavior is
>>>> changed such that fields are read/written but discarded, without
>>>> updating the spec, then the "undefined" behavior at least becomes
>>>> safer.
>>>>   If the behavior is changed, *and* the spec is updated, then we get
>>>> both benefits, but at the cost that all previous implementations will
>>>> not be compliant with the spec.
>>>>
>>>> All options seem to have a cost though.
>>>
>>> In the JDK, java.util.Date does not read/write fields.  Perhaps others
>>> as well.  Given that the behavior is presently undefined, that means
>>> the serialized representation of java.util.Date (and any other such
>>> non-conforming classes) are also undefined.
>>>
>>
>
>


-- 
- DML