local variable scope

[Pramod P Deore]

Local Inner class Cannot refer to a non-final variable inside an inner class defined in a method. Because A local variable, exists only during the method invocation. Means there scope is limited to that particular method. Now when I changed to it as final there scope also changes? Means local variables are stored on stack. and if I declared local variables as final now they are stored on Heap? What is the scope of final local variables?

[Darryl Burke]

No. As I understand it, the complier inserts a field in the inner class and passes the value of the final local variable to this field via a constructor parameter. All this is done transparently, of course.

[Pramod P Deore]

Hi Darryl thanks for reply, But I couldn't get it, will you please explain it. Thanks

[Henry Wong]

Pramod P Deore wrote:Hi Darryl thanks for reply, But I couldn't get it, will you please explain it. Thanks

Basically, if the method local variable is declared as final, and has already been set at the point of the inner class instantiation... then the compiler makes a copy of the value. The inner class has a field variable, that is set the value, and the inner class isn't really accessing the method local variable. This is all done automagically -- from the code, it just looks like the method local variable is being accessed.

Henry

[Jeff Verdegan]

We can't really share the same variable, since the local one's lifetime will probably be shorter than the inner object's lifetime. By making it final, the compiler can make a copy, and using that copy looks like we're using the same variable, since the value can't change.

[Pramod P Deore]

Thanks Henry and Jeff now I got it.

[Rajdeep Biswas]

Jeff Verdegan wrote:We can't really share the same variable, since the local one's lifetime will probably be shorter than the inner object's lifetime. By making it final, the compiler can make a copy, and using that copy looks like we're using the same variable, since the value can't change.

So, final local variables get special allocation? Where? Is the treatment same for method-local and class-level final variables?
How the problem at https://coderanch.com/t/578809/java-programmer-SCJP/certification/method-local-inner-classes is explained?

[Jeff Verdegan]

Rajdeep Biswas wrote:

Jeff Verdegan wrote:We can't really share the same variable, since the local one's lifetime will probably be shorter than the inner object's lifetime. By making it final, the compiler can make a copy, and using that copy looks like we're using the same variable, since the value can't change.

So, final local variables get special allocation?

Nope. There are two completely independent variables: The local variable, and a "hidden" variable that the compiler generates for the nested class. When we refer to the local variable by name in the nested class, uner the covers, it actually refers to that synthetic variable that the compiler generated. The local variable has the same allocation, scope, and lifetime as always, and the nested class's variable has scope and lifetime appropriate to the local class, as if it were declared there in our code.

If these variables were not final, things would get weird, because we'd think we have a single variable, but since there are actually two, independent ones, we could change the variable in one place and not see that change in the other place.

So, by requiring the local variable to be final the behavior of two independent variables is the same as if it were a single variable. The only special treatment is 1) The local is required to be final, and 2) The compiler generates a copy that we don't see in our code.

[Henry Wong]

Jeff Verdegan wrote:

Rajdeep Biswas wrote:

Jeff Verdegan wrote:We can't really share the same variable, since the local one's lifetime will probably be shorter than the inner object's lifetime. By making it final, the compiler can make a copy, and using that copy looks like we're using the same variable, since the value can't change.

So, final local variables get special allocation?

Nope. There are two completely independent variables: The local variable, and a "hidden" variable that the compiler generates for the nested class. When we refer to the local variable by name in the nested class, uner the covers, it actually refers to that synthetic variable that the compiler generated. The local variable has the same allocation, scope, and lifetime as always, and the nested class's variable has scope and lifetime appropriate to the local class, as if it were declared there in our code.

If these variables were not final, things would get weird, because we'd think we have a single variable, but since there are actually two, independent ones, we could change the variable in one place and not see that change in the other place.

So, by requiring the local variable to be final the behavior of two independent variables is the same as if it were a single variable. The only special treatment is 1) The local is required to be final, and 2) The compiler generates a copy that we don't see in our code.

While I believe that Jeff is absolutely corrent here.... if memory serves, it's also merely an implementation detail. The Java Language Specifcation just requires that the local variable be declared as final, and be assigned prior to the declaration of the body of the inner class.

Henry

[Jeff Verdegan]

Henry Wong wrote:
While I believe that Jeff is absolutely corrent here.... if memory serves, it's also merely an implementation detail. The Java Language Specifcation just requires that the local variable be declared as final, and be assigned prior to the declaration of the body of the inner class.

Good point. The spec is more likely to define what behavior must be observed--and put as little restriction on how to make it happen in order to not break whatever else the spec allows and requires--and not say much about how that behavior comes about. Possibly final is required because if it weren't, correct behavior couldn't be guaranteed in a manner consistent with other parts of the spec. Beyond that, though, the "hidden variable" is, as you say, most likely an implementation detail, not a requirement.

I haven't actually looked at that part of the spec in great detail, nor recently, so I'll leave the final confirmation up to the reader. (In other words, I'm feeling lazy and can't be bothered. )

[Rajdeep Biswas]

Thank you Jeff and Henry, and the confusion creators of course! final leads to correct behavior, as a copy of it is passed to the local inner class.