[concurrency-interest] Joda-Time immutability

Brian Goetz brian at briangoetz.com
Tue Jun 21 19:35:42 EDT 2011

Its not obvious that a combination of (b) and (c) can't work, with 
sufficient tweaking in readObject/writeObject/readResolve/writeReplace 
among the three classes.  What you want is for the deserialization to 
recognize whether this is an "old" or "new" serialized form, and behave 
accordingly.  A combination of logic in readObject (which can detect the 
serialized form) and readResolve (which will serve up an instance of a 
different class if it detects the old form) seems like it should do it.

> 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...
> 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
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest

More information about the Concurrency-interest mailing list