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