Nice to @Share?

[Reinier Zwitserloot]

If anyone is going to run an analysis of the single-element array pattern to
have mutable local variables accessible from anonymous inner classes, keep
the following in mind:

single-element array is just one way to do it. 2 other ways:

 - AtomicInteger, AtomicReference, and friends.

 - A custom Pointer<T> class:

 public class Pointer<T> {
     public T value;
     public Pointer(T initial) { this.value = initial; }
}


this class may not be called Pointer and could look quite different.

 - Turning the local variable into a field instead (with all the pain that
entails for threading issues, but, nevertheless, it is one possible way
around this issue).


As with many forays into existing code to see if a certain feature is needed
or not, the very fact that a feature does not exist means code has been
designed to work around the lack of said feature.

--Reinier Zwitserloot



On Tue, Feb 23, 2010 at 10:39 AM, Neal Gafter <neal at gafter.com> wrote:

> On Tue, Feb 23, 2010 at 1:22 AM, Alex Buckley <Alex.Buckley at sun.com>
> wrote:
> > As Neal said, @Shared is mentioned in non-normative text lifted directly
> > from John Rose's mail. I have never thought it appropriate for an
> > annotation to turn a local variable into a shared variable. That is,
> > once a method-scoped variable is morally "shared", it isn't a local
> > variable (stack-allocated, single-thread-visibility, no volatility) at
> > all. It's an eighth kind of variable in JLS 4.12.3. (And being 'final'
> > is orthogonal.) A restricted keyword - suggestions welcome - is more
> > than appropriate.
>
> The definition of "local variable" in (§4.12.3) is "Local variables
> are declared by local variable declaration statements (§14.4).
> Whenever the flow of control enters a block (§14.2)  or for statement
> (§14.14), a new variable is created for each local variable declared
> in a local variable declaration statement immediately contained within
> that block or for statement. A local variable declaration statement
> may contain an expression which initializes the variable. The local
> variable with an initializing expression is not initialized, however,
> until the local variable declaration statement that declares it is
> executed. (The rules of definite assignment (§16) prevent the value of
> a local variable from being used before it has been initialized or
> otherwise assigned a value.) The local variable effectively ceases to
> exist when the execution of the block or for statement is complete."
>
> The only part of that requiring rewording in the presence of lambdas
> that can access local variables from the enclosing scope is the last
> sentence.  The rewording is required whether or not such variables are
> final.  In fact, that last sentence appears to conflict with the fact
> that final variables can be accessed in an anonymous inner class after
> the scope containing the variable has completed.
>
> A new keyword, while better than what programmers have to do today, is
> still boilerplate.
>
>