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.ander...@oracle.com Sent from my iPad On Feb 15, 2014, at 8:35 AM, Martijn Verburg <martijnverb...@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.ll...@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.ll...@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 >>
