Mark Reinhold on Closures for Java
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.
"The principle use case for Java closures is parallel programming."
What they won't be...
* Capture of non-ﬁnal variables,
* Non-local transfer of control, and
* Library-deﬁned control structures (i.e., control abstraction).
At present I see no need to add any of these to Java.
Which begs the question - I can throw lambdas to Fork&Join and friends, but I can't write a parallel map/for using lambdas because that would be a library defined control structure?
Please note: they're called lambads, not closures
Evolving Culture and Values. Understanding the Tradeoffs. Growth through Failure. The Importance of Leadership and Open Communication.
Pedram Keyani Mar 11, 2014
Summly: An Award Winning Mobile App's Journey to the Cloud with Five-9s Availability on a Shoestring Budget
Eugene Ciurana Mar 11, 2014
Christophe Achouiantz Mar 11, 2014