A hole in the serialization spec

[David M. Lloyd]

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.
-- 
- DML