There is an arguably nicer way to do this now that we have Generics: http://luolong.blogspot.com/2010/06/delicious-wraps.html
teisipäev, 13. september 2011 1:28.41 UTC+3 kirjutas KWright: > > 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 view this discussion on the web visit https://groups.google.com/d/msg/javaposse/-/ObrBeZH7EPsJ. 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.
