A hole in the serialization spec

[Lance @ Oracle]

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