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

From: Jerry Schwarz (jerry.schwarz@oracle.com)
Date: Thu May 27 2004 - 13:33:09 EDT

At 09:24 PM 5/26/2004, Sylvia Else wrote:

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?


Permitted. There is no reason to treat this any differently than

class Outer {
    static int[] x = new int[1];
}

class Inner {
     Inner() {
          Outer.x[0] = 42;
     }
     int get() {
           return Outer.x[0];
     }
}



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