views:

112

answers:

3

In Java an anonymous inner class can refer to variables in it's local scope:

public class A {
    public void method() {
        final int i = 0;

        doStuff(new Action() {
            public void doAction() {
                Console.printf(i);   // or whatever
            }
        });
    }
}

My question is how is this actually implemented? How does i get to the anonymous inner doAction implementation, and why does it have to be final?

+6  A: 

Local variables are (obviously) not shared between different methods such as method() and doAction() above. But since it's final, nothing "bad" could happen in this case, so the language still allows it. The compiler however, needs to do something cleaver about the situation. Lets have a look at what the compiler produces:

$ javap -v "A\$1"           # A$1 is the anonymous Action-class.
...
final int val$i;    // A field to store the i-value in.

final A this$0;     // A reference to the "enclosing" A-object.

A$1(A, int);  // created constructor of the anonymous class
  Code:
   Stack=2, Locals=3, Args_size=3
   0: aload_0
   1: aload_1
   2: putfield #1; //Field this$0:LA;
   5: aload_0
   6: iload_2
   7: putfield #2; //Field val$i:I
   10: aload_0
   11: invokespecial #3; //Method java/lang/Object."<init>":()V
   14: return
   ...
public void doAction();
  Code:
   Stack=2, Locals=1, Args_size=1
   0: getstatic #4; //Field java/lang/System.out:Ljava/io/PrintStream;
   3: aload_0
   4: getfield #2; //Field val$i:I
   7: invokevirtual #5; //Method java/io/PrintStream.println:(I)V
   10: return

This actually shows that it

  • turned the i variable into a field,
  • created a constructor for the anonymous class, which accepted a reference to the A object
  • which it later accessed in the doAction() method.

(A side note: I had to initialize the variable to new java.util.Random().nextInt() to prevent it from optimizing away a lot of code.)


Similar discussion here

http://stackoverflow.com/questions/2764035/question-regarding-the-method-local-innerclasses-accesing-the-local-variables-of/2764130

aioobe
It has nothing (much) to do with threading. It's merely a side-effect. Nice java disasm, btw: gives some great insight into the compiler.
Pindatjuh
You're right. I'll revise. Thanks for the pointer.
aioobe
@Pindatjuh, Updated the disasm... realized it optimized away a lot of code as the compiler realized `i` was always 0.
aioobe
+1 Disassembling with `javap` is a good idea for questions like this, more people should try that more often to learn how the Java compiler works.
Jesper
The variable `i` is **not** turned into a field. The local variable `i` of the method `A.method()` is still a local variable. The variable `var$i` of the innerclass `A$1` mentioned in your javap fragment is **another** variable. The `int` argument of the constructor `A$1(A, int)` is the current (and only) value of `i`, and the constructor saves that value in the field `val$i`.
Christian Semrau
Excellent answer, would accept both answers if I could
thecoop
+3  A: 

The local class instance (the anonymous class) must maintain a separate copy of the variable, as it may out-live the function. So as not to have the confusion of two modifiable variables with the same name in the same scope, the variable is forced to be final.

See http://stackoverflow.com/questions/2320762/java-final-an-enduring-mystery/2320774#2320774 for more details.

Chris Dennett
+2  A: 

The compiler automatically generates a constructor for your anonymous inner-class, and passes your local variable into this constructor.

The constructor saves this value in a class variable (a field), also named i, which will be used inside the "closure".

Why it has to be final? Well let's explore the situation in where it isn't:

public class A {
    public void method() {
        int i = 0; // note: this is WRONG code

        doStuff(new Action() {
            public void doAction() {
                Console.printf(i);   // or whatever
            }
        });

        i = 4; // A
        // B
        i = 5; // C
    }
}

In situation A the field i of Action also needs to be changed, let's assume this is possible: it needs the reference to the Action object.

Assume that in situation B this instance of Action is Garbage-Collected.

Now in situation C: it needs an instance of Action to update it's class variable, but the value is GCed. It needs to "know" it's GCed, but that is difficult.

So to keep the implementation of the VM simpler, the Java language designers have said that it should be final such that the VM doesn't need a way to check whether an object is gone, and guarantee that the variable is not modified, and that the VM or compiler doesn't have to keep reference of all usages of the variable inside anonymous inner-classes and their instances.

Pindatjuh
Actually, the synthesized variable that holds a copy of the variable is not named i. Depending on which version of the compiler you're using it is "$i" or "+i".
Neal Gafter