The Forgotten Argument for Closures in Java (original) (raw)

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).

This argument can be debated in two ways:

(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.