A hole in the serialization spec
David M. Lloyd
david.lloyd at redhat.com
Fri Feb 14 15:56:34 UTC 2014
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
More information about the core-libs-dev
mailing list