[concurrency-interest] Joda-Time immutability

David Holmes davidcholmes at aapt.net.au
Mon Jun 20 07:15:48 EDT 2011

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:

    DateTime / MutableDateTime


    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

    Concurrency-interest mailing list
    Concurrency-interest at cs.oswego.edu

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

More information about the Concurrency-interest mailing list