The Forgotten Argument for Closures in Java
Background
This article is an excellent summary of the various closures proposals for Java 7+.
However, in the opening paragraphs, it implies that the case for closures are:
(a) a closure is a classic, useful programming construct
(b) the cool languages have them and enjoy increased expressive power
This is all well and good.
But Wait
However, there is another argument, as espoused by Neal Gafter (and reported by Alex Miller). Essentially, it is as follows:
- Multicores are coming (the free-lunch is over).
- Brian Goetz is cooking up a new fork-join library for concurrency (JSR 166).
- BGGA closures simplify the API for JSR 166 (as evidenced by a prototype).
(a) do we still want closures, even with this info?
(b) which closure proposal is the best for this simplification?
With respect to (b), it may well be true that the other proposals also simplify the API.
Either way, this is a major motivator and thus a central argument.
The Upshot
Don't be fooled by posts that imply that the closures proposals are "keeping up with Scala or C#" or especially "driven by the elite language lawyers" (which drives me crazy).
As Dick Wall has said, we should assume that all of the key players are earnestly trying to do the right thing for Java.
One of those things is simplifying Java's use of multicores. You may still argue against closures, or BGGA, but be sure to include it in your analysis.
ps. One may well ask for a simple, concrete example of the simplification with BGGA. Alas, I don't have one at hand (the JavaDoc is provided here, but it is not a good illustration). Please post a link in the comments if you have worked with the prototype.
8 comments:
You can see Brian Goetz's examples from his concurrency talk at JavaOne at this page which links to both the audio recording and PDF.
In the slides, you can see a non-closure example in slide 28 and the closures version at the end in slide 34. I would reproduce them here but it would not be pretty.
If you're interested in concurrency, you cannot go wrong listening to the audio and reading the slides for this talk - one of the highlights of JavaOne 2008 for me.
Much in line with what you are saying, I myself am hobbled by a lack of understanding for what closures grant you: there are already many cases where you can use Continuation Passing Style data structures and cooperative yield already, it just takes some careful engineering of your program. NIO is ideal for this, & the Servlets 3.0 spec should enable something akin to continuations in the webserver. I'd love to see some good examples of functionality continuations grant thats not possible with code-level CPS alone.
@Alex. Thanks mate
@rektide. I think we agree that it would be nice to have examples. However, your comment reads a bit as though I am suggesting there is a lack of understanding for what closures buy us. For me, this is not true: closures can be very useful. IMO, they are a 'niche tool' compared to say, collections, but the truth is Java has successfully evolved to the point where 'niche' is the new frontier.
Everyone should definitely check out the link posted by Alex above. This prime stuff and absolutely a window to the future for parallelism in Java.
As Alex mentions, the final slides show closures in action.
In the JavaOne talk I didn't see anything that was closure specific, inner classes with short syntax would be just as elegant. Inner classes have many advantages in this context, like inheritance, named and documented actions, and thread safety. With closures you need closure conversions and restricted closures for parallel operations and you still don't have inheritance and you still need to deal with a two type systems.
Post a Comment