most languages with closures allow this but not what is currently being
proposed in Java 8. Closures in Java 8 currently do not permit capture of
mutable local variables.
7. Local variable capture
--------------------------
The current rules for capturing local variables of enclosing contexts
in inner classes are quite restrictive; only final variables may be
captured. For lambda expressions (and for consistency, probably inner
class instances as well), we relax these rules to also allow for
capture of *effectively final* local variables. (Informally, a local
variable is effectively final if making it final would not cause a
compilation failure.)
It is likely that we will *not* permit capture of mutable local
variables. The reason is that idioms like this:
int sum = 0;
list.forEach({ Element e -> sum += e.size(); });
are fundamentally serial; it is quite difficult to write lambda bodies
like this that do not have race conditions. Unless we are willing to
enforce (preferably statically) that such lambdas not escape their
capturing thread, such a feature may likely cause more trouble than it
solves.
On Mon, Sep 12, 2011 at 5:44 PM, Josh Berry <[email protected]> wrote:
> On Mon, Sep 12, 2011 at 4:54 PM, clay <[email protected]> wrote:
> > The "final" keyword, means that the variable reference itself can't be
> > modified, but it doesn't impose or suggest any restrictions on the
> > contents of the variable.
> >
> > You can absolutely mutate/change the contents of a final variable and
> > communicate state through that between different closures or different
> > parts of the application.
>
> So, make a 2 closures and then alternate calling each where the first
> increments an int, and the second prints it.
>
> That is,
>
> public void foo() {
> int myInt = 0;
> Runnable a = new Runnable() {
> public void run() {
> myInt++;
> }
> };
> Runnable b = new Runnable() {
> public void run() {
> System.out.println(myInt);
> }
> };
> a.run();
> b.run();
> }
>
> If we had closures, you could do this, no? (Again, not being
> rhetorical. This is just how I understand the situation.)
>
> --
> You received this message because you are subscribed to the Google Groups
> "The Java Posse" group.
> To post to this group, send email to [email protected].
> To unsubscribe from this group, send email to
> [email protected].
> For more options, visit this group at
> http://groups.google.com/group/javaposse?hl=en.
>
>
--
You received this message because you are subscribed to the Google Groups "The
Java Posse" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/javaposse?hl=en.
