I'll not speak about final class variables. I'll not speak about sense of declaring method arguments final. I try to find out side effects of declaring method variables as final. It is about scope, lifetime of those referencies and by this possible memory leaks caused.
We all know:
A variable or reference to a variable declared final can be assigned a value only once. That's fine.
We know too, a variable, or it's reference declared within a method lives for the scope of the method. (Is put on the stack)
Declaring a variable, or better said a reference to a heap Object within a method, which must be passed to a new thread, mostly declared as an anonymous inner class, must be declared final.
So what is the exact mechanism? A copy of the final reference is put on the parameter list of the annonymous class constructor and by this the new thread can access the object on the heap.
What happens to the reference declared final on the method stack?
Either normal reference or reference declared final, on exit of the method scope is gone. But now are they handled identical? Nulled out? Or how does the garbage collector know the heap object can be destroyed if the previously started thread loose scope too?
If the handling of both kind of referencies is identical, why must we declare a reference final if it ist passed to a new thread?
I couldn't understand your confusion properly, but if suppose I declare a final reference to lets say an Employee object, and use in a new Thread (declared as an anonymous inner class), then that Employee object will be eligible for garbage collection when the reference in the containing method and the anonymous inner class are out of scope. The reference in the anonymous inner class is at the class level so it will go out of scope the the instance of the anonymous inner class itself is eligible for garbage collection (i.e. the run method of the thread completes and the reference to the anonymous inner class in the containing method is out of scope or set to null)...
Oh, thanks for answering.
From the article about anonymous classes, I deduce, final is just to make clear that the reference can not be modified and there are no further constraints below the hood.
In fact those constraints I'm interesting in, not the superficial behaviour and rules.
Of course, I can open the Java Spec. and read through until I got the answer. The reason of my question, was just to save me from that! If somebody just knows the answer, it is so much easier than reading Java Spec.