The free lunch is over.
Multicore processors are not just coming—they’re here.
Leveraging multiple cores requires writing scalable parallel programs, which is incredibly hard.
Tools such as fork/join frameworks based on work-stealing algorithms make the task easier, but it still takes a fair bit of expertise and tuning.
Bulk-data APIs such as parallel arrays allow computations to be expressed in terms of higher-level, SQL-like operations (e.g., filter, map, and reduce) which can be mapped automatically onto the fork-join paradigm.
Working with parallel arrays in Java, unfortunately, requires lots of boilerplate code to solve even simple problems.
Closures can eliminate that boilerplate.
It’s time to add them to Java.
The closures design space 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.
A couple of other integration features worth considering are first-class method references and the ability of function types to include exception parameters.
Some of the other features found in the existing proposals carry considerable additional complexity:
Capture of non-final variables,
Non-local transfer of control, and
Library-defined control structures (i.e., control abstraction).
At present I see no need to add any of these to Java.
Let’s be about it It’s time to learn from the past debate and move forward. 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.
Revising a programming language that’s in active use by millions of developers is no small task. Sun neither can nor should do it alone, so I hereby invite everyone who participated in the earlier closures conversations—as well as anyone else with an informed opinion—to join us.