Effectively final effective?

[Reinier Zwitserloot]

On Fri, Feb 26, 2010 at 4:25 AM, Jesse Kuhnert <jkuhnert at gmail.com> wrote:

> If anonymous inner classes are something everyone thinks shouldn't be
> there anyway then they shouldn't be considered too strictly. Shouldn't
> they become obsolete with this project anyways?
>
>
No. Anonymous Inner Classes will become obsolete as a way to do
closure-esque things. They will not be obsolete for e.g. inline
specification of for example a WindowListener, or really any other
on-the-fly specification of an interface or (usually abstract) class in a
place that really requires an object and not a function.


> The threading issues do sound like something worthwhile exploring very
> thoroughly though,  given the predominent environment the language
> runs in.  Tough choice there..
>

There are so many different sentiments floating around that its hard to tell
the forest from the trees, but as far as I understand it, these are the
three sentiments I've heard:

 1. Variables accessed in closures should be silently moved into the heap. I
haven't yet heard anything from this camp about what to do with "volatile",
which would be a useful construct to them have on such local variables. This
is somewhat tricky when the closure is run in another thread.

 2. Variables accessed in closures will be made implicitly final. Any
attempt to mutate them, either in the closure or outside of it, generates a
compiler error. This camp is furthermore split into two: One camp wants a
keyword of some sort to get #1 behaviour (so, _explicit_ movement to the
heap), the other says that AtomicReference, AtomicInteger, and friends are
good enough.

 3. Variables accessed in closures will be silently copied, with the copy
inside the closure being final, but the variable outside of it being mutable
(but, as the closure gets a copy, any mutations don't show up in the
closure). I've filed this away as crackpot, where it'll hopefully remain, as
this is going to be very surprising to a lot of programmers and the only way
this surprise is going to become obvious is after many hours spent
debugging.

 4. As with anonymous inner classes, variables cannot be accessed at all
inside closures unless they are marked explicitly final.


I'd say that with no distinction between safe and unsafe closures, Only
option #2 (either variant), with option #4 as a very distant second, is
sensible, and with safe/unsafe closures, Option #1 for unsafe closures, and
either #2 or #4 for safe closures, seems reasonable. Exactly how to proceed
is no clear to me, as this discussion seems to be heading into a painting
the bike shed direction.


NB: Jesse, regardless of the pros and cons of making a backwards
incompatible java 2.0 release, Java 7 most assuredly is not going to be such
a release, so whatever ideas you come up with, if they aren't backwards
compatible, the only way its going to happen is for closures to not make it
into Java7, and for Java8 to be a Java 2.0 release, which even then is very
very unlikely. Mark Reinhold explicitly mentioned during Devoxx that he
considers any attempt to make Java 2.0 to be rife with second version
syndrome.


> On Thursday, February 25, 2010, Paulo Levi <i30817 at gmail.com> wrote:
> > Final should have been the default, non null should have been in the
> > language (and default), constructors should have not been allowed to call
> > protected methods, closures should have come on day one, reification
> should
> > have been included in generics, i miss map and reduce on arrays & lists,
> i
> > like list generators and RIIA and would love it in java.
> >
> > The discussion is if it is worthwhile to allow final by default for
> captured
> > variables in lambdas considering that
> > a) anonymous classes have the opposite behavior, so things get slightly
> > inconsistent.
> > b) it is safer for threaded use.
> >
> >
>
>