Closures, too much or too little?

[Reinier Zwitserloot]

auto-final can be combined with @Shared (with @Shared being one option when
you access a mutating variable from outer scope), though once auto-final is
in place, I don't think @Shared is a make-or-break kind of issue with
closures.


As mark mentioned, it DOES happen though (probably will happen a lot more,
when closures are added in JDK7), and people use a number of different
solutions to get around this. This is a bad thing. I've seen arrays, I've
seen AtomicReference and friends, and I've seen hand-rolled Pointer classes.
I've even used all 3, though I've standardized myself on always using an
Atomic* for it, whether or not I actually need the atomicity.

Is there any pragmatic argument AGAINST adding @Shared to the language,
other than "Any feature should prove why we have to add it, not why we
shouldn't", and hazy concerns about keywordishness, which seems like a taste
fight, not an actual discussion, not to mention solvable by replacing
"@Shared" with public.

My personal preference lies in auto-final *AND* @Shared.

--Reinier Zwitserloot

On Mon, Nov 23, 2009 at 5:18 PM, Joshua Bloch <jjb at google.com> wrote:

> I'm still not convinced that it's a good idea to allow closure to capture
> shared local variables.  I do (still) like the idea of "auto-finalization"
> (i.e., it's OK for a closure or anonymous class instance creation
> expression) to reference a local variable that's not explicitly labeled
> final if DU/DA-style analysis shows it to be effectively final.  I suspect
> this is the sweet spot.
>
>             Josh
>
> On Mon, Nov 23, 2009 at 7:58 AM, <tronicek at fit.cvut.cz> wrote:
>
> > Hi Howard,
> >
> > you can argue similarly for example in case of method overriding and
> > overloading and suggest to add the "override" and "overload" keywords. I
> > do not mind if the "shared" or "public" keyword is mandatory in this
> case.
> > However, mandatory annotation is odd for me.
> >
> > Z.
> > --
> > Zdenek Tronicek
> > FIT CTU in Prague
> > http://kenai.com/projects/refactoringng - refactoring tool for compiler
> > guys
> >
> >
> > Howard Lovatt napsal(a):
> > > Hi Zdenek,
> > >
> > > The following example from Josh Bloch illustrates why I would rather
> > > writable captured variables generate an error if you miss off @Shared:
> > >
> > > public class Test {
> > >
> > >     private static final int N = 10;
> > >
> > >     public static void main(String[] args) {
> > >
> > >         List<{ => int}> closures = new ArrayList<{ => int}>();
> > >
> > >         for (int i = 0; i < N; i++)
> > >
> > >             closures.add( { => i } );
> > >
> > >         int total = 0;
> > >
> > >         for ({ => int} closure : closures)
> > >
> > >             total += closure.invoke();
> > >
> > >         System.out.println(total);
> > >
> > >     }
> > >
> > > }
> > >
> > > This example is almost certainly an error; therefore I feel a warning
> is
> > > insufficient, much like "int i = 2.0;" is almost certainly an error and
> I
> > > would find a warning insufficient for this too. To me the warnings that
> > > are
> > > in Java currently are all dubious; they are just a fudge because of
> some
> > > other problem, e.g. erasure.
> > >
> > > With regard to annotations, if people really like the concept that an
> > > annotation should not be like a keyword then make shared a keyword (I
> am
> > > happy either way). I think Josh Bloch has suggested reusing public, but
> I
> > > would prefer either shared or @Shared.
> > >
> > >  -- Howard.
> > >
> >
> >
> >
>
>