RE: JavaMemoryModel: Re: Are this$x fields final?

From: Sylvia Else (syljmm32@cryogenic.net)
Date: Thu May 27 2004 - 00:24:23 EDT


Consider this contrived scenario

public class Outer {
     final int[] x = new int[1];

     class Inner {
         Inner() {
             x[0] = 42;
         }

         int get() {
             return x[0];
         }
     }
}

static Outer.Inner inner;
Thread 1
         Outer outer = new Outer();
         inner = outer.new Inner();

Thread 2

     int r = inner.get();

Behaviour in question: r == 0;

If the reference to the outer class is final, then the behaviour is
prohibited, otherwise it is permitted. So which should it be?

At 07:48 PM 26/05/2004 -0700, Jerry Schwarz wrote:

>Creating an "as-if" rule is the proper way to proceed. References to
>this$x are obviously implementation hacks. But the above isn't the right
>rule. What programmers need is a guarantee that references to an class
>always work. That is, they never generate a null pointer. Personally I
>think this is implicit in the language definition of inner classes and JSR
>133 doesn't need to say anything about it. But I wouldn't object to some
>clarification.
>
>If people need more synchronization than that then they should implement
>it themselves. Saying that the inner class always has a final field has
>implications for its constructors that we don't need. It associates being
>an inner class with a property (how it's constructors behave) that doesn't
>seem to have any relationship to the property of being an inner class.

-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel



This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:01:08 EDT