BT

Mark Reinhold on Closures for Java

by Charles Humble on Nov 25, 2009 |

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.

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

"The principle use case for Java closures is parallel programming." 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.

Re: 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.

What they won't be... 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?

Please note: they're called lambads, not closures 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.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

4 Discuss

Educational Content

General Feedback
Bugs
Advertising
Editorial
InfoQ.com and all content copyright © 2006-2014 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT