JavaMemoryModel: Re: Are this$x fields final?

From: Bill Pugh (
Date: Tue May 25 2004 - 14:40:42 EDT

Yes, you are right about 17 with substituted at compile time.
Actually, with this$0 being final, we'll be guaranteed to see the
correct value for x
without x being final (due to the transitive guarantees for final

So amend the example to have x non-final:

class A {
  int x = 17;
  class B {
         int getX() {
                 return x;
  static B b;

Initially, A.b is initialized to be some B object.

Then, we have two incorrectly synchronized threads that perform:

Thread 1:
A.b = new B()

Thread 2:
r1 = A.b.getX();

How and where do we document the thread safety properties of references
to outer instances?
Clearly, just giving this example doesn't define a semantics. I can see
why you don't want to define
the mechanism by which instances gain access to a surrounding
instances. But giving the thread safety
semantics without talking about that mechanism is going to be difficult.


On May 25, 2004, at 2:30 PM, Neal Gafter wrote:

> These synthetic fields are always final. So no synchronization is
> required.
> On the other hand, this$0 isn't involved in your example, because x is
> a constant. The generated code for getX() is
> bipush 17;
> ireturn;
> There is no opportunity for a null pointer exception.
> -Neal

JavaMemoryModel mailing list -

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