[concurrency-interest] Joda-Time immutability

David Holmes davidcholmes at aapt.net.au
Mon Jun 20 19:41:49 EDT 2011


Stephen Colebourne writes:
> Does this work?
>
> class DateTime extends BaseDateTime {
>  private transient volatile fixBadDesign;
>
>  publc DateTime(long millis) {
>    super(millis);
>    fixbadDesign = this;
>    DateTime fixed = fixbadDesign;
>  }
>
> }

No, writing to a volatile is not sufficient. As I said previously writing a
final field might suffice.

David

> Stephen
>
>
> On 20 June 2011 18:45, David M. Lloyd <david.lloyd at redhat.com> wrote:
> > On 06/20/2011 12:32 PM, Stephen Colebourne wrote:
> >>
> >> On 20 June 2011 17:52, Attila Szegedi<szegedia at gmail.com>  wrote:
> >>>
> >>> Well, to me it looks like it's implemented:
> >>> import java.lang.reflect.Field;
> >>> public class TestFinalField {
> >>>   public final int x = 1;
> >>>   public static void main(String[] args) throws Exception {
> >>>     TestFinalField tff = new TestFinalField();
> >>>     Field f = tff.getClass().getField("x");
> >>>     f.setAccessible(true);
> >>>     f.set(tff, 2);
> >>>     System.out.println(tff.x);
> >>>   }
> >>> }
> >>> This prints "1", and not "2". So, setting of a final field is actually
> >>> silently ignored with setAccessible(true), for better or
> worse. Without
> >>> setAccessible(), it will actually throw an exception. With the "final"
> >>> qualifier removed from the field, it prints "2", as expected.
> I tested it
> >>> with both latest Java 6 and on the b145 build of OpenJDK 7, and both
> >>> behaves
> >>> as described.
> >>
> >> Well thats weird, because my change works and passes the tests in
> >> Joda-Time.
> >>
> >>
> https://github.com/JodaOrg/joda-time/commit/067983f2684fa9e9ca4af4
ef73b09e2be2f70001#diff-8
>>
>> Anyone know what is going on? Can this be sufficiently relied on? I
>> haven't really got a workable alternative.
>
> AFAIK the only time you can count on this working is if you've constructed
> an object instance without calling its constructor (a la serialization).
 In
> other words the JVM is allowed to assume that the final field won't change
> and optimize accordingly.
>
> I wouldn't rely on this trick for updating a field outside of a
readObject()
> method.
>
> --
> - DML
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>

_______________________________________________
Concurrency-interest mailing list
Concurrency-interest at cs.oswego.edu
http://cs.oswego.edu/mailman/listinfo/concurrency-interest




More information about the Concurrency-interest mailing list