Mark Reinhold on Closures for Java

Posted by Charles Humble on Nov 25, 2009

Community

Java

Topics

Language ,

Language Design

Tags

Language Features ,

Closures

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.

1. Back to top

   "The principle use case for Java closures is parallel programming."

   Nov 25, 2009 7:55 AM by Lukas Bradley

   Would someone please send me a link to describe why closures are related to parallel programming. Every example I have seen utilizes inline processing.

   Reply

2. Back to top

   Re:

   Nov 25, 2009 8:08 AM by William H

   I thought the article linked to in Mark's blog - www.ibm.com/developerworks/java/library/j-jtp03... - did a pretty good job of explaining this. Most of the new JDK7 concurrency libraries (Fork/Join and Parallel Array for instance) require a lot of boiler plate to make them work. So much so that I believe ParallelArray is currently out-of-scope of Java 7 though the revised deadline might allow it back in.

   Reply

3. Back to top

   What they won't be...

   Nov 25, 2009 9:36 AM by Werner Schuster

   I found this bit from Mark's blog item interesting:
   

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

   
   
   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?

   Reply

4. Back to top

   Please note: they're called lambads, not closures

   Nov 26, 2009 2:32 AM by Alex Blewitt

   alblue.blogspot.com/2009/11/java-will-have-lamb... describes the difference between lambdas and closures, and the fact that the new proposal correctly calls them lambdas.

   Reply

• Older >