Android (Java) Learning Note 150: Why a local inner class can only access a final type constant in an external class

Why the anonymous intrinsic class parameter must be a final type:

1) from the theory of the programming language: The local inner class (i.e., the inner class defined in the method ), because it is inside the method itself (can appear at the formal parameter definition or method body), thus accessing the method of the local variables (formal parameters or local variables) is natural, it is naturally.

2) Why add a restriction to Java: Only the final type local variables can be accessed?

The designer of the Java language compiler is of course fully implemented: The local inner class can access all the local variables in the method (because: Theoretically this is a natural requirement), but: the compilation technique is either impossible or extremely expensive .

As for why it can only be final, not staic, although both should be accessible from the scope of the internal class, sun may consider more security because variables of the static type are permanently changed by the inner class. This is not advisable .

3) Where is the difficulty?

The life cycle of the local variable is inconsistent with the life cycle of the local inner class object!

E.G1:

The method F is called to generate the variable i in its call stack, which results in a local inner class object Inner_object, which accesses the local variable I. When the method F () runs, the local variable i is dead and does not exist. However: the local inner class object Inner_object may also persist (it will only die if no one references the object again), and it will not end up dead with the method F () running. At this point: there is a "ridiculous" result: the local inner class object Inner_object to access a nonexistent local variable i!

E.G2:

How can it be achieved? When the variable is final, the copy is copied directly as a data member in the local interior by "copying" the final local variable. This way: when the internal class accesses local variables, the local variable is actually accessed by the "replica" (that is, the copy represents the local variable). Thus: When a real local variable in the run stack dies, the local inner class object can still access the local variable (actually accessing the "replica"), giving the impression that the "lifetime" of the local variable is prolonged.

Summarize:

The core question is: How can you make: access to the "replica" and access to the real original local variables, the semantic effect is the same ?

When the variable is final, if the base data type, because its value is unchanged, thus: its copy is the same as the original amount. The semantic effect is the same. (if: Not final, there is no guarantee that the copy is consistent with the original variable because: the original variable is changed in the method, and the local inner class is replaced by a copy)

When a variable is final, a reference type, because its reference value is constant (that is, always pointing to the same object), and thus: its copy, like the original reference variable, always points to the same object (because it is final, thus guaranteeing: only point to this object, and then not to other objects), to achieve: Replicas accessed in the local inner class are always the same as the original objects accessed in the method code: The semantic effect is the same. Otherwise: When the original variable is changed in the method, and the local inner class is changed, there is no guarantee that the copy is consistent with the original variable (so: they should have been the same variable.)

Bottom line: The rule is a helpless one. It also shows that the design of programming language is limited by the implementation technology. This is one example. Because: I see a lot of people hold this view: design and ideas are the most important, the implementation of the technology is irrelevant, as long as you make the design and rules, can be achieved.

Android (Java) Learning Note 150: Why a local inner class can only access a final type constant in an external class