[concurrency-interest] Joda-Time immutability

Christian Vest Hansen karmazilla at gmail.com
Mon Jun 20 07:00:54 EDT 2011


Any volatile write at the end of the DateTime constructors would order all
of the writes by the BaseDateTime constructors to happen-before a reference
to the constructed DateTime object is returned to the instantiator (if that
is a word).
You would thus end up with a safely published, effectively immutable object
*assuming* the `this` reference does not escape from the constructors.

On Mon, Jun 20, 2011 at 12:33, 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...
>
> 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
>



-- 
Venlig hilsen / Kind regards,
Christian Vest Hansen.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20110620/8f8b7807/attachment.html>


More information about the Concurrency-interest mailing list