Nice to @Share?

[Alex Buckley]

Neal Gafter wrote:
> Too bad, because the sentence is already incorrect.  Local variables
> that happen to be final and used in an inner class do not cease to
> exist when the execution of the block is complete.

Local variables that are final and accessed from an anon.inner class are 
compiled to non-local variables, right? They are local from the p.o.v. 
of JLS3 1-16 but not local from the p.o.v. of the JMM, which ended up as 
JLS3 17.

A "shared local variable" defined in 1-16 would no more be a local 
variable in 17 than a "final local variable" is a local variable in 17.

I pointed out 17.4.1 to show that "local variable" has always been 
assumed to mean the same in 1-16 as in 17. But the assumption is 
incorrect, as I realized for 'shared variables' and you realized for 
'final local variables'. 17 could be changed to treat all method-scoped 
variables in the language as local variables in the JMM, but that will 
not happen.

As you indicated, JLS3 15.12.4.5 is a masterpiece of wording that puts 
local variables in an "activation frame", separate from the stack. 
Shared variables will live in the frame along with final and non-final 
local variables. But it seems to me that shared variables are a more 
dangerous language construct than final local variables, and deserve to 
be called out in the language. JMM-inspired assumptions around locality 
should be stripped away with extreme prejudice.

Come to think of it, JLS3 8.1.3 would ideally say something other than 
"local variable" in:

"Any local variable, formal method parameter or exception handler 
parameter used but not declared in an inner class must be declared 
final. Any local variable, used but not declared in an inner class must 
be definitely assigned (§16) before the body of the inner class."

Alex