Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

#104 ISOChronology serialization broken

closed
Joda-Time (76)
6
2012-10-08
2010-11-24
Anonymous
No

ISOChronology is serialized with ISOChronology$Stub. Its internal state is stored in a transient field, so after serialization it may be incorrect.

Real issue: Create LocalDate in UTC as 2010/11/24. Serialize it, and deserialize in Pacific time zone - you get 2010/11/23 in America/Los_Angeles.

See also: http://stackoverflow.com/q/4268472/277683

Discussion

  • Oh foobar. Just shows that tens of thousands of tests and 5 years of use doesn't catch everything...

     

  • Anonymous
    2010-11-24

    Quite a show stopper for me, since serialization is a critical requirement. Why use transients for serialization?

    Same thing with DateTimeZone$Stub.

     

  • Anonymous
    2010-11-24

    As someone at StackOverflow pointed out, the root cause is my serializer - Hessian. It does not seem to respect writeObject().

     
  • OK, after looking more closely I see how the transient field is used, and there is no bug in Joda-Time.

    While I'd love to remove the transient field, it increases the size of a typical ISOChronology from 126 to 165 bytes, which isn't acceptable to fix a Hessian bug.

     

  • Anonymous
    2010-12-01

    Unfortunately, that is the case. Joda itself is correct, but this way it doesn't work with custom serializers including Hessian and Beanlib. It is a shame, but -- for the sake of compatibility, how about providing private default constructor and setters/getters?

    By the way, I believe it is ISOChronology what is used 99% of the time. It could be serialized as null. And Local* types don't need a time zone. These two changes would make it much smaller.

     
  • I examined what it would take to alter this. Basically, any changes would either require extra 4 bytes in every DateTime/LocalDate or the use of PutField in serialisation. I suspect that PutField would not be supported by these tools either. And I'm not willing to add 4 bytes to each object. Plus, any change would mean that objects serialised with the new version couldn't be read by the old.

    I might consider a check on the local classes to ensure that the chronology is UTC, although I don't really think I should as its other tools that are broken.

     
  • I won't fix the main part of this call, but have added readResolve to handle the non-compliant other tools better.