Why Java inner classes require "final" outer instance variables? [duplicate]

Question

final JTextField jtfContent = new JTextField();
btnOK.addActionListener(new java.awt.event.ActionListener(){
    public void actionPerformed(java.awt.event.ActionEvent event){
        jtfContent.setText("I am OK");
    }
} );

If I omit final, I see the error "Cannot refer to a non-final variable jtfContent inside an inner class defined in a different method".

Why must an anonymous inner class require the outer classes instance variable to be final in order to access it?

Sonatina

I note that this question is older than the question it is claimed to be a duplicate of. – Stillhunt

@Stillhunt according to respective meta discussion, timing of questions doesn't really matter: Should I vote to close a duplicate question, even though it's much newer... - "If the new question is a better question or has better answers, then vote to close the old one as a duplicate of the new one..." – Culler

can someone explain why in Java 1.8 this code passes compilation? – Comorin

Because in Java 8, it allows variable that is final or effectively final to pass the compiler here. – Norge

@bruno Shouldn't this be w.r.t 'local' variables or method parameters and not outer 'instance' variables? – Tahoe

@Tahoe correct. The title is misleading and nobody has addressed that in the answer. Please can someone get it fixed? – Erigena

I have proposed an edit. – Erigena

Answer 1

Well first, let's all relax, and please put that gun down.

OK. Now the reason the language insists on that is that it cheats in order to provide your inner class functions access to the local variables they crave. The runtime makes a copy of the local execution context (and etc. as appropriate), and thus it insists that you make everything final so it can keep things honest.

If it didn't do that, then code that changed the value of a local variable after your object was constructed but before the inner class function runs might be confusing and weird.

This is the essence of a lot of the brouhaha around Java and "closures".

---

Note: the opening paragraph was a joke in reference to some all-caps text in the original composition of the OP.

Malinin

I had this happen to me once with Javascript. It was hard to find! – Backset

is it a shallow copy the runtime makes of the local execution context or a deep copy ? I tried to test this and it seems its a shallow copy, can you confirm.? – Mellar

@Mellar that's a good question; I strongly suspect it's a shallow copy (so, if you've got a final reference to a mutable object, the object will be mutable via code in the pseudo-closure). Making deep copies is generally a hard problem and I think it would be extremely unlikely for it to work that way. – Malinin

It is absolutely a shallow copy. There is no magic "deep copy" mechanism in Java. – Munford

Yes the primitive types are copied "by value" as always in java, and everything else is a shallow copy. Thanks to the garbage collector this kind of shallow copy is easy to implement. – Whimsical

@Malinin To keep things in sane/sync it should be (has to be) a shallow copy else mutable objects with final will make no sense, right? – Tahoe

@Tahoe If I understand your question, yes. – Malinin

But is it actually possible to change the value of local variable after our object is constructed but before the inner class function runs? How would we do it if we didn't have to make local variables final? – Caplin

@Caplin well what I do is perform whatever work I need to perform with the non-final local variables, and then copy any results into other final variables that exist solely to make the "fake closure" work. It's very ugly but if I worried about ugly stuff in Java I'd be a very depressed person. – Malinin

@Malinin it’s the same thing when you want to initialize a final field, e.g. try { MY_CONSTANT = foo(); } catch(SomeException ex) { MY_CONSTANT = foo(); } doesn’t work; the solution is the same as for a variable you want to capture. So it’s actually unrelated to closures, it’s just about the strictness regarding definite assignment. – Mushroom

Answer 2

The methods in an anonymous class don't really have access to local variables and method parameters. Rather, when an object of the anonymous class is instantiated, copies of the final local variables and method parameters referred to by the object's methods are stored as instance variables in the object. The methods in the object of the anonymous class really access those hidden instance variables. [1]

Thus, the local variables and method parameters accessed by the methods of the local class must be declared final to prevent their values from changing after the object is instantiated.

[1] http://www.developer.com/java/other/article.php/3300881/The-Essence-of-OOP-using-Java-Anonymous-Classes.htm

Parcenary

+1 for explicitly pointing out that the limitation (until java 8) was w.r.t local variables and method parameters and not instance variables. – Tahoe

Answer 3

The variables around the definition of the class live on the stack, so they are probably gone when the code inside the inner class runs (if you want to know why, search stack and heap). That's why inner classes don't actually use the variables in the containing method, but are constructed with copies of them.

This means that if you change the variable in the containing method after constructing the inner class, its value won't change in the inner class, even though you'd expect it to. To prevent confusion there, Java requires them to be final, so you expect not to be able to modify them.

Serdab

I think this is the best answer. local variables live on the stack. But class live on the heap. So JVM copies this variables via it's constructor method. But if the variables changed, this two value are different. – Nasopharynx

Answer 4

The reason is that Java do not fully support so-called "Closures" - in which case the final would not be necessary - but instead have found a trick by letting the compiler generate some hidden variables which is used to give the functionality you see.

If you disassemble the generated byte code you can see how the compiler does it, including the strangely named hidden variables containing copies of the final variables.

It is an elegant solution to give functionality without bending the language backwards to do so.

---

Edit: For Java 8 lambdas give a more concise way to do what was previously done with anonymous classes. The restrictions on variables have also loosened from "final" to "essentially final" - you do not have to declare it final, but if it is treated like it is final (you could add the final keyword and your code would still compile) it can be used. This is a really nice change.

Foolhardy

instead of "an elegant" I might have said "inelegant" instead, but it is what it is. I guess it's a bit better in java8... :) – Tewfik

Elegant syntaxwise. And -as always - feel free to write a better answer. – Sisto

Answer 5

Since Java 8 final modifier is optional for outer instance variables. Value should be 'effectively final'. See answer Difference between final and effectively final.

Smalto