A hole in the serialization spec

[roger riggs]

Hi,

Not likely to deprecate Date due to the pervasive use.
But it is highly unlikely that java.util.Date will be evolving, since 
java.time exists
there is no need or desire to add any functionality to Date.   But it is 
just one case
of the serialized form issues that are being discussed.

Roger


On 2/15/2014 11:40 AM, Lance @ Oracle wrote:
> IMHO, I think that is a tall task.  There is such a large base of code that uses it or java.sql.Date, that having warnings for deprecation will cause a lot of angst.  That code is not going to migrate quickly, if at all to the new types.
>
> Best
> Lance
>
>
> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
> Oracle Java Engineering
> 1 Network Drive
> Burlington, MA 01803
> Lance.Andersen at oracle.com
> Sent from my iPad
>
> On Feb 15, 2014, at 8:35 AM, Martijn Verburg <martijnverburg at gmail.com> wrote:
>
>> In the long term will it be possible to just mark j.u.Date as deprecated
>> since the new Date and Time libs have come in?  Avoids having to fix old
>> behaviour that folks might be relying on.
>>
>> Cheers,
>> Martijn
>>
>>
>> On 14 February 2014 18:56, David M. Lloyd <david.lloyd at redhat.com> wrote:
>>
>>> 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
>>>