Of course, there's the old trick of making a "final" single element array, and passing that into your lambda expression/anonymous inner class/whatever. The cell of that array can still happily be changed at a later point and the "closure" will see this mutated value when executed.
Get a few of these going without due diligence and, if you find race conditions funny, let the hilarity ensue! And no, I'm not advocating that anybody does such a thing. On 12 September 2011 23:17, Serge Boulay <[email protected]> wrote: > 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.
