we cannot access local variable in a local class inside a method because the life of a local variable is only the execution of that method as mentioned in K&B pg 645. But my question is why we can access local variable ,when we use 'final' modifier with the local variable. Thanks in Advance for reply. [ June 14, 2007: Message edited by: raj malhotra ]
You might ask, why do the local variables have to be final? Could not the compiler just as well take a copy of non-final local variables, much the way it does for a non-final parameters? If it did so, you would have two copies of the variable. Each could change independently, much like caller and callee's copy of a parameter, however you would use the same syntax to access either copy. This would be confusing. So Sun insisted the local be final. This makes irrelevant that there are actually two copies of it.
I am not getting everything from it .can you make clear what the author means by saying two copy of variables? [ June 14, 2007: Message edited by: raj malhotra ]
i havn't got your point, can you clarify it a bit more.........
thanks in advance
Joined: Feb 22, 2007
My point is that local class can access instance variable of the enclosing outer class.But it cannot use the local variables defined in method ,in which it is also defined.But the only way it can access local variable is if local variable is declared final.
My question is by using final keyword with y what make it special that we can use y but not x.
In this case the LocalClass instance created inside getLocalClassInstance will 'survive' the method call, as its reference its returned to the main method. Now, when you call the close() method, the LocalClass instance will need variable i. The problem with that is that i is a local variable, and therefore lives in the stack (when the method call finishes, it is said to be 'destroyed'). What the JVM does in this case is to create a copy of variable i somewhere else (I am not sure, but I think that should be in the heap). Imagine what will happen if variable i were not final. The JVM will need to synchronize the values of both copies every time method getLocalClassInstance() or the LocalClass instance modifies their respective copy. That would be a nightmare with very little benefits. That is why variable i (in this example) is required to be final, so that the compiler knows that it cannot be modified once its value is set.
OK, I'm going to over simplify a bit but this is a slightly complicated topic ...
(By the way you missed an 'int' out on your y declartion)
First consider my version of your class ...
At line A) I create my class x and y exist but they're on the stack, not allocated in main memory (i.e. via new) i.e. in C++ land they have no memory address, when you exit your method disp they conceptually cease to exist .. but look I could read them using my new getter methods. If I called getX from outside the method disp (using the returned variable were would it get X from, X has been cleaned up and gone (unless as they say they had made a copy which they don't).
What they are saying is they could have got round this by copying x and y and tying them to the life time of your new class BUT its then not obvious they are copies and several gotcha's ensue (hint: imagine if the disp method took an Object as a parameter which was really a LocalClass)
For a final as you can't alter it the fact you have a copy is irrelevant i.e. if y=5 the fact you have two y's is no problem as there both 5.
Think of in this case final not as a variable but as a C++ define statement where it just cuts and pastes the text '5' everywhere you write 'y' before compilation rather than having a real bit of memory containing a value and it makes it simpler to understand for me anyway.
PS Yes this is confusing :-)
"Eagles may soar but weasels don't get sucked into jet engines" SCJP 1.6, SCWCD 1.4, SCJD 1.5,SCBCD 5