[concurrency-interest] Joda-Time immutability

Daniel Yokomizo daniel.yokomizo at gmail.com
Mon Jun 20 07:13:26 EDT 2011


On Jun 20, 2011 7:40 AM, "Stephen Colebourne" <scolebourne at joda.org> wrote:
>
> In Joda-Time way back when we structured the code in a complex manner
> and then claimed immutability. This is causing difficulty to try and
> obey proper immutability standards, and I'd like any ideas on fixes.
>
> Consider the "immutable" class DateTime. The hierarchy is as follows:
>
> AbstractInstant
> AbstractDateTime
> BaseDateTime
> DateTime / MutableDateTime
>
>
https://github.com/JodaOrg/joda-time/tree/master/src/main/java/org/joda/time
>
https://github.com/JodaOrg/joda-time/tree/master/src/main/java/org/joda/time/base
>
> The two Abstract prefixed classes are not an issue, as they just share
> code and contain no state. However the BaseDateTime contains all the
> state (and DateTime/MutableDateTime contain no state).
>
> As a result of this (bad) design, the instance variables in
> BaseDateTime are not final (as they need to be mutated by the
> MutableDateTime subclass). The DateTime ("immutable") subclass is thus
> storing its state in regular mutable variables in BaseDateTime. Under
> the memory model, claiming DateTime as immutable is wrong.
>
> Making changes to fix this is easy, however making changes and
> preserving backwards compatibility (which is very important here) and
> performance (also important) appears to be very tricky at the moment,
> and thats what I'd like thoughts on.
>
> Options considered:
> a) Change BaseDateTime instance variables to final. No - it breaks the
> mutable subclass
>
> b) Move instance variables down from BaseDateTime to DateTime and
> MutableDateTime. No - Serialization broken (deserialization contains
> the data, but it tries to populate BaseDateTime, not DateTime).
>
> c) Try to do something clever with serialization to read the fields in
> manually. No - can't then store the read data as the instance variable
> has to be final...

Wouldn't a serialization proxy (i.e. readResolve/writeReplace) solve this?

> d) Change the instance variables to be volatile. Seems like an
> overhead (especially for a performance sensitive class like this).
> Doesn't seem ideal when 99% of the uses will use the "immuable" class
> where its effectively final in nature.
>
> Have I missed an idea? Is there any way to say at the end of a
> constructor "please publish this state as I promise it won't change
> later"?!
>
> Stephen

Best regards,
Daniel Yokomizo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20110620/ea09cb17/attachment.html>


More information about the Concurrency-interest mailing list