[concurrency-interest] Joda-Time immutability

Stephen Colebourne scolebourne at joda.org
Mon Jun 20 06:33:52 EDT 2011


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


More information about the Concurrency-interest mailing list