foreword
Reprinted from: http://feiyeguohai.iteye.com/blog/1500108
1. From the theory of programming language: a local inner class (ie: an inner class defined in a method), because it is inside the method (may appear at the definition of formal parameters or at the body of the method), it accesses the inner class in the method. Local variables (formal parameters or local variables) are natural. It is very natural.
2. Why is there a restriction in JAVA: only final local variables can be accessed?
3. The designer of the JAVA language compiler of course wants to achieve "local inner classes can access all local variables in the method" (because this is a natural requirement in theory), but such compilation technology cannot be realized or realized The price is high.
4. Where is the difficulty? Where is the difficulty?
The inconsistency between the life cycle of local variables and the life cycle of objects of local inner classes!
5. Suppose the method f() is called, thereby generating the variable i in its call stack , and at this time generating a local inner class object inner_object, which accesses the local variable i .
When the method f() finishes running, the local variable i is dead and no longer exists. But the local inner class object inner_object may still exist (only when no one refers to the object, it will die), it will not die with the end of the method f() running.
At this time, there is a "ridiculous" result: the local inner class object inner_object wants to access a local variable i that no longer exists !
6. The solution to this problem
When the variable is final, by "copying" the final local variable, the copy is directly used as the data member in the local internal. In this way, when a local inner class accesses a local variable, it actually accesses the "copy" of the local variable (that is, the copy represents that local variable). Therefore, when the real local variable in the running stack dies, the local inner class object can still access the local variable (in fact, the access is the "copy"), which gives the impression that the "lifetime" of the local variable is extended.
How can we make: accessing the "copy" and accessing the real original local variable, the semantic effect is the same?
When the variable is final, if it is a basic data type, because its value does not change, therefore: its copy is the same as the original The amount is the same. The semantic effect is the same. (If: not final, there is no guarantee: the copy is consistent with the original variable, because: the original variable is changed in the method, and the copy is changed in the local inner class)
When the variable is final, if it is a reference type, since its reference value does not change (that is, it always points to the same object), its copy will always point to the same object as the original reference variable (because it is final, thus ensuring that : can only point to this object, no other objects), to achieve: the copy accessed in the local inner class and the original object accessed in the method code are always the same, that is: the semantic effect is the same. Otherwise: when the method When changing the original variable in the local inner class, and changing the copy in the local inner class, there is no guarantee: the copy is the same as the original variable (so: they should be the same variable originally.)
Summarize
In a word: This regulation is a kind of helpless. It also shows that the design of programming language is limited by the implementation technology. This is an example. Because: I have seen many people hold this view: design and ideas are the most important Importantly, the technology of implementation is irrelevant, as long as you make the design and regulations, it can be implemented.