Nice to @Share?

Joshua Bloch jjb at google.com
Mon Feb 22 13:37:55 PST 2010


Zdenek,

Hi!

On Mon, Feb 22, 2010 at 1:07 PM, Zdenek Tronicek <tronicek at fit.cvut.cz>wrote:

> Joshua Bloch napsal(a):
> >  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).
>
> I think the annotation is only for local variables. As far as I know, in
> the BGGA prototype it is not used for fields.
>

That may have been the case in some BGGA proposal(s), but the prose that I
quoted (which included the phrase "all kinds of variables") came straight
from a discussion section of the vurrent (0.1.5) draft of the Project Lambda
proposal.

>
> > (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.
>
> In the BGGA prototype, the annotation was meant as confirmation "I am
> aware that this variable may be shared between threads". It does not
> change the semantics because the variable can be captured even if it does
> not have this annotation. In such case, the compiler emitted warning that
> the captured variable is not annotated.
>

Understood. But the BGGA proposal was different in many ways, as it had very
different goals. In this proposal, one practical alternative (as per the
current normative text) is to ban outright the capture of local variables
that are not final or effectively final. This requires programmers to use
the well-known single-element array (or wrapper object) idiom in the rare
case where they really do want to close over a mutable local variable. If we
decide that we really must provide a more concise syntax (and I'm not at all
sure that we should), then I believe a new modifier is justified (not an
annotation), and that "shared" is a poor choice of name. I'm not sure what a
good name would be, but I won't think about until we've decided that we
really want such a thing. Think of it as lazy evaluation;)

               Josh


More information about the lambda-dev mailing list