Nice to @Share?

[Neal Gafter]

On Wed, Feb 24, 2010 at 9:52 AM, Alex Buckley <Alex.Buckley at sun.com> wrote:
> 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?

Right, but unfortunately the JLS doesn't say that (yet).

> 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.

Right, that is how it should be.

> 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.

Agreed.

> 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.

Excellent!

> 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.

That makes sense, presuming that calling out is really required to get
the semantics right. If its value is primarily tutorial, then it does
not belong in normative text.