[concurrency-interest] Joda-Time immutability

Stephen Colebourne scolebourne at joda.org
Mon Jun 20 07:24:22 EDT 2011

So would this work at the end of the constructor?

class DateTime extends BaseDateTime {
  private transient volatile fixBadDesign;

  publc DateTime(long millis) {
    fixbadDesign = this;
    DateTime fixed = fixbadDesign;


I can't make the field final without breaking backwards compatibility
somewhere (its version 2.0, so I have some small ability to break 1%
of users, but I won't break the 99%, break serialization, or
compromise performance)


On 20 June 2011 12:15, David Holmes <davidcholmes at aapt.net.au> wrote:
> A volatile write would only work if there were a corresponding volatile
> read.
> Final field semantics might give the necessary guarantee.
> David Holmes
> -----Original Message-----
> From: concurrency-interest-bounces at cs.oswego.edu
> [mailto:concurrency-interest-bounces at cs.oswego.edu]On Behalf Of Christian
> Vest Hansen
> Sent: Monday, 20 June 2011 9:01 PM
> To: Stephen Colebourne
> Cc: concurrency-interest at cs.oswego.edu
> Subject: Re: [concurrency-interest] Joda-Time immutability
> 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.

More information about the Concurrency-interest mailing list