Following on from last week's surprise announcement at Devoxx that Sun would be adding closures to Java, Mark Reinhold has published a blog entry providing more background to the decision.
The principle use case for Java closures is parallel programming. Reinhold argues that using tools such as parallel arrays requires too much boiler plate code in Java, and that by introducing closures to the language it is possible to eliminate that boilerplate. He goes on:
In the last few years three serious proposals for adding closures to Java have been put forward: BGGA, CICE, and FCM. These proposals cover a wide range of complexity and expressive power. My view, having studied them all, is that each contains good ideas yet none is entirely appropriate for a "working programmer's language".To support the principal use case of parallel programming we really only need two key features:
- A literal syntax, for writing closures, and
- Function types, so that closures are first-class citizens in the type system.
To integrate closures with the rest of the language and the platform we need two additional features:
- Closure conversion, so that a closure of appropriate type can be used where an object of a single-method interface or abstract class is required, and
- Extension methods, so that closure-oriented bulk-data methods can be retrofitted onto existing libraries, and in particular the Collections Framework, without breaking compatibility.
Java is often criticised for the slow pace of its evolution. Whilst the argument is often overplayed (Java has been through 4 major revisions since C++ was last updated for example) anything that encourages language experimentation within Java is positive, provided it can be done in a way that doesn't impact the language directly. In a previous article I explored three alternative techniques that allow this - DSLs, the Java 6 annotation processor, and moving the default place for adding syntactic sugar from the language to the IDE - but whilst each of these techniques is useful we found that each had its limitations when attempting to provide support for closures. Sun's solution is to use the JDK 7 project itself to do the experimentation before deciding whether to standardise the feature for Java SE. As Reinhold puts it:
Sun will initiate the design and implementation of a simple closures feature, as outlined above, and add it to JDK 7 so as to enable broad experimentation. If all goes well then we'll later submit a language-change JSR which would, in turn, be proposed as a component of the eventual Java SE 7 JSR.
Sun is keen to here from "everyone who participated in the earlier closures conversations - as well as anyone else with an informed opinion" and a straw man proposal is expected soon.
