JDK 7 Unexpectedly Gets “Simple” Closures, but is Pushed Back to End of 2010

During his Devoxx talk, Mark Reinhold has announced that JDK 7 will have Closures.  With the inclusion of this much debated feature, JDK 7 schedule will be extended until around September 2010.

Joseph D. Darcy, lead engineer of Project Coin, which aims to make small language changes for Java 7, has confirmed that the next version of the language will include some kind of “lightweight” Closures:

… JDK 7 will have closures, a to-be-developed from of closures smaller than BGGA, and that the JDK 7 schedule will also be extended until around September 2010.

Alex Miller who attended the talk points out that Sun has been negative about Closures although the community had produced 3 different proposals in the past:

I can’t say what to make of that really. For years Sun has been saying that there is no consensus on closures and delayed the formation of a JSR or expert group on the subject despite having three proposals, all with prototypes.

After the announcement at Devoxx, Neal Gafter who was a co-author for one of the three Closures proposals (BGGA, named after the initials of Bracha, Gafter, Gosling, and von der Ahé), has released a “simplified proposal”:

Changes in this revision

• The control invocation syntax has been moved to a separate specification.
• The term closure literal has been replaced by lambda expression.
• We overhauled the syntax for lambda expressions, borrowing loosely from Clang. There are now two forms of lambda expression: an expression lambda has a controlled expression, while a statement lambda has a controlled statement.
• The term closure object has been replaced by function object.
• The term closure conversion has been replaced by lambda conversion, with a separate block conversion for the control invocation syntax.
• Added new semantics for the return statement: it can now be used to return from a statement lambda.
• Renamed java.lang.Unreachable to java.lang.Nothing ala Scala.
• Removed support for the type name null. The previous version used null as a placeholder for an exception type when none can be thrown. The type Nothing now serves that purpose.
• Overhauled restricted. The concepts of restricted and unrestricted function types and closures have been removed. Now, all lambda expressions are restricted. The equivalent of the previous specification's unrestricted closure may be passed to a method by using the control invocation syntax.
• Added support for method references: We added support for treating a reference to a method as a function using a newly introduced token #. The syntax is borrowed from cross-references in javadoc and the FCM proposal.

This sudden change in plans for JDK 7 has made people like Fabrizio Giudici skeptic about the decision process:

I don't want to discuss whether it's a good or a bad thing (you know I think it's bad I suspend any judgment as I understand that the proposal is neither BGGA nor CICE, but something new). I'm only appalled that after a few weeks that the final word of Java 7 had been said with Project Coin (the famous final five or so), somebody changed his mind all of a sudden. What kind of decisional process is this?

Ah, I got it - it's tossing a coin, now I get where the project name came from. I fear Java 7 could be the most chaotical Java release ever - a very good idea if you want to kill it prematurely (as it there weren't already many other sources of entropy, such as the Oracle deal or the Jigsaw / OSGi debate).

Similarly Geertjan Wielenga thinks that the inclusion of Closures was a very unexpected development:

Great news and maybe best if no one asks too many questions about how that process ended up throwing up this solution! First, we have a whole bunch of proposals, all of which get lukewarm reception. Then, suddenly, like a bolt from the blue, we have "simple closures". (I wonder if any of the existing proposals are called "complex closures". Isn't simplicity the whole purpose of closures in the first place?) OK, the closures will be simple in the sense that there will be no non-local return, no control statements, and no access to non-final variables. Still, how was that decision made?

Cay Horstmann, provides several use cases for this new BGGA proposal, which is very similar to the FCM proposal:

We don't really know what exactly Sun intends to do. I simply analyzed the BGGA 0.6a proposal, which is presumably what BGGA is today. There is no denying that it looks a lot like FCM. No non-local returns. # for lambda. Since you need to annotate a mutated variable with @Shared when you capture it, perhaps people would think twice before writing

    foreach(@Shared String v : values) 
   		funcs.add( #() => v);

As Alex Miller mentions, the extension of the JDK schedule might make it possible for other features to make it into the release, like the the ParallelArray library which provides a functional style API for mapping, filtering, reducing over an array of Java objects:

I talked to Bob Lee a bit at QCon and he thought it was possible that the extended timeline for JDK 7 may allow the ParallelArray work to come back in and make use of the new closure support.

You can find more information about Closures and JDK 7 right here on InfoQ!