Nice to @Share?

[Reinier Zwitserloot]

"public" as a keyword on local variable declarations and method parameters
avoids the need to mess with (restricted) new keywords, is backwards
compatible, and there is some (but admittedly not a lot) semantic harmony
between public fields and methods, and local variables that end up declared
on the heap, potentially accessible by multiple threads, etc. I'm not sure
if there is a single short word that covers both the meaning and
repercussions of letting a local variable be accessible by lambdas. In that
case, 'public's intrinsic benefits, i.e. it being an existing non-restricted
keyword, makes for a strong case.

Second point: Consider allowing access from anonymous inner classes as well?
Just because we'll have shiny new lambdas doesn't mean anonymous classes are
going to go away or start gathering dust!

--Reinier Zwitserloot



On Tue, Feb 23, 2010 at 10: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.
>
> Alex
>
> Joshua Bloch wrote:
> > Some say it's nice to @Share, but not me. Draft 0.1.5 of the Project
> Lambda
> > spec contains some discussion of an @Shared annotation to "allow
> unqualified
> > references to upplevel variables (all sorts) if they are marked @Shared."
> >  There are several reasons that I believe this not a good idea:
> >
> > (1) For fields (instance or static) this annotation is not required today
> > (in anonymouns class instance creation expressions), and I believe that
> > programmers are likely to see it as an added annoyance (like the current
> > situation with final variables).
> >
> > (2) For local variables, I see it as too much magic:
> >
> >     @Shared int i;
> >
> >  has a totally different implementation from:
> >
> >     int i;
> >
> > The latter creates a "container object" on the heap, the former doesn't.
> The
> > semantics (in particular, the lifetime) and the performance are likely to
> > differ significantly.
> >
> > (3) I believe it's an abuse of annotations.  Some may liken it to
> @Override,
> > but I believe this is specious. The @Override annotation merely expresses
> a
> > compile-time assertion that the compiler is able to verify. The proposed
> > @Shared annotation changes the semantics of the language.
> >
> > (4) If, in spite of all the above, it is the consesnsus that such an
> > annotation is still a good idea, I believe the name @Shared could hardly
> be
> > more misleading. In practical terms, it means "this variable must *not*
> be
> > shared (without additional synchronization)." It would typically be used
> > when the programmer could assert that the variable in question would
> never
> > be sharead among multiple threads.
> >
> >             Josh
> >
>
>