65
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?

bruno
  • 2,213
  • 1
  • 19
  • 31
Adham shafik
  • 1,044
  • 1
  • 13
  • 16
  • 4
    I note that this question is older than the question it is claimed to be a duplicate of. – Raedwald Jul 20 '13 at 11:41
  • 2
    @Raedwald 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...](http://meta.stackexchange.com/q/147643/165773) - _"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..."_ – gnat Jul 20 '13 at 15:08
  • can someone explain why in Java 1.8 this code passes compilation? – Strin Jul 09 '14 at 19:12
  • 3
    Because in Java 8, it allows variable that is final or *effectively final* to pass the compiler here. – Victor Wong Jan 23 '15 at 10:03
  • @bruno Shouldn't this be w.r.t 'local' variables or method parameters and not outer 'instance' variables? – sactiw Jun 18 '15 at 10:45
  • @sactiw correct. The title is misleading and nobody has addressed that in the answer. Please can someone get it fixed? – rents Apr 16 '17 at 20:39
  • I have proposed an edit. – rents Apr 16 '17 at 20:47

5 Answers5

81

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.

Pointy
  • 405,095
  • 59
  • 585
  • 614
  • I had this happen to me once with Javascript. It was hard to find! – Alexander Suraphel Dec 16 '15 at 15:06
  • 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.? – j2emanue Mar 06 '16 at 16:32
  • 2
    @j2emanue 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. – Pointy Mar 06 '16 at 16:34
  • 2
    It is absolutely a shallow copy. There is no magic "deep copy" mechanism in Java. – DavidS Mar 16 '16 at 20:22
  • 1
    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. – Mike76 Aug 27 '16 at 13:17
  • @Pointy 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? – sactiw Apr 19 '17 at 13:53
  • @sactiw If I understand your question, yes. – Pointy Apr 19 '17 at 13:55
  • 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`? – getsadzeg May 07 '19 at 16:30
  • 1
    @getsadzeg 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. – Pointy May 07 '19 at 16:31
  • 1
    @Pointy 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. – Holger Jan 14 '20 at 12:26
26

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

Jorge Ferreira
  • 96,051
  • 25
  • 122
  • 132
  • 1
    +1 for explicitly pointing out that the limitation (until java 8) was w.r.t local variables and method parameters and not instance variables. – sactiw Jun 18 '15 at 10:44
13

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.

Bart van Heukelom
  • 43,244
  • 59
  • 186
  • 301
  • 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. – Charon Chui Jun 18 '21 at 13:03
9

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.

Thorbjørn Ravn Andersen
  • 73,784
  • 33
  • 194
  • 347
7

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

Community
  • 1
  • 1
anstarovoyt
  • 7,956
  • 2
  • 27
  • 35