Summary
The three competing proposals to add closures to the Java language reached a consensus, according to Neal Gafter, co-author of one of the proposals. The consensus clears the way to submit to the JCP a JSR request for adding closures to Java.
Advertisement
Many developers recognize that closures are a powerful programming construct, and several competing proposals emerged over the past few months to facilitate adding closures to the Java language.
After months of debates, Neal Gafter, co-author of one of the proposals announced on his blog that a consensus was reached, and that the authors of the three proposals all agreed to stand behind one JSR request to add closures to the Java language:
[This] JSR proposal ... represents a consensus among the folks thinking about this area... Our latest JSR proposal comes as close to achieving consensus as I believe possible. All but one of the authors of the three widely-discussed closures proposals have agreed to support it.
The purpose of the JSR proposal is to define the problems to be solved and circumscribe the permitted solution space. It doesn't mandate a particular solution, though it does offer the Closures for Java specification as an example of a solution to many (but not all) of the problems. This should not be surprising, as that spec was written specifically in an attempt to satisfy the requirements.
What do you think of the consensus closures proposal?
Apparently consensus is not the mother of discussion ;) I tried reading it, but I didn't find a solid description of what the api would look like, just a lot of "would be similar to" type references... Did I miss something or do I not know how to read JSRs?
As I've said previously, I think the return semantics they are choosing are wrong. The UnmatchedNonlocalTransfer exception stuff just seems crazy to me, especially when the first "Open Issue" is:
Make it easy to yield a result early from a closure. It should be as easy to yield a result early from a closure as returning from a method.
What are they going to do, add a "reallyReturn" keyword? A return statement should return from the closure, not from the scope at which it was defined.
As a side light, I'm unclear on how a value is returned from a multi-statement closure in their proposal even if they do stick with their return semantics. Is it the value of the last expression executed? The only example I saw was a simple expression body.
The "Closure Conversion" section is great. We will never again have to look at some ridiculous anonymous Runnable object! Hooray! That's some good, quality welding.
I'm not sure I understand the "Control invocation syntax" section. Seems like they are trying to mirror Ruby's "magic block" feature which I've grown to dislike. _shrug_ If it's a price I have to pay to get closures in Java, I'll gladly pay it.
All in all, it could have been much worse. Now the question is: will it make it in?
Previous Topic
