A hole in the serialization spec

[David M. Lloyd]

On 02/14/2014 09: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.

An interesting detail here - since Date doesn't have any non-transient 
fields, this happens to work out OK for a second reason (that 
defaultReadFields() would read nothing anyway) - however it still would 
break if a non-transient field were to be added.

-- 
- DML