[concurrency-interest] Joda-Time immutability

Stephen Colebourne scolebourne at joda.org
Wed Aug 3 13:18:29 EDT 2011


On 3 August 2011 09:42, Zhong Yu <zhong.j.yu at gmail.com> wrote:
> The fix with `volatile` is incorrect. Another thread may observe an
> uninitialized field - writing the volatile field and publishing `this`
> reference can be reordered. Only a `final` field can prevent that.

Would that not require the constructor to expose the reference to 'this'?

In the DateTime class, the 'this' reference is not exposed as far as I can see:
https://github.com/JodaOrg/joda-time/blob/master/src/main/java/org/joda/time/DateTime.java
https://github.com/JodaOrg/joda-time/blob/master/src/main/java/org/joda/time/base/BaseDateTime.java
https://github.com/JodaOrg/joda-time/blob/master/src/main/java/org/joda/time/base/AbstractDateTime.java
https://github.com/JodaOrg/joda-time/blob/master/src/main/java/org/joda/time/base/AbstractInstant.java

> The original problem is not about making updates to the field visible
> to other thread - MutableDateTime was never intended to be thread
> safe.
Agreed. MutableDateTime does not need to be thread-safe. I only care
about the immutable classes being truly immutable.

> My understanding is that it can be fixed like this:
>
>    class Base // immutable
>
>        final state;
>
>        getState(){ return state; }
>
>        method(){ calculate( getState() ); }
>
>    class Derived extends Base // mutable
>
>        my_state;
>
>        setState( state ){ my_state=state; }
>
>        @Override
>        getState(){ return my_state? my_state : super.getState(); }

Such a design might work, but would change the serialization of the
mutable class.

Stephen



More information about the Concurrency-interest mailing list