Closures in Java 7

Question

So is Java 7 finally going to get the closures? What's the latest news?

Answer 1

Yes, closures were include to release plan of java 7 (and it was the most significant reason to delay release from winter to autumn (expected in September 2010)).

The latest news could be found at Project Lambda. You may also be interested in reading latest specification draft.

Answer 2

There is no official statement on the state of closures at the moment.

Here are some readable examples of how it could work and look like.

If you want to get some insight into what's going on I refer you to the OpenJDK mailing list.

Overview

Basically there is some hope, because code together with some tests were already committed to some source code branch and there are at least some halfway working infrastructure to test it.

The change message from Maurizio Cimadamore reads:

initial lambda push; the current prototype suuports the following features:

• function types syntax (optionally enabled with -XDallowFunctionTypes)
• function types subtyping
• full support for lambda expression of type 1 and 2
• inference of thrown types/return type in a lambda
• lambda conversion using rules specified in v0.1.5 draft
• support references to 'this' (both explicit and implicit)
• translation using method handles

The modified script build of the langtools repository now generates an additional jarfile called javacrt.jar which contains an helper class to be used during SAM conversion; after the build, the generated scripts javac/java will take care of automatically setting up the required dependencies so that code containing lambda expressions can be compiled and executed.

But this is ongoing work and quite buggy at the moment. For instance the compiler sometimes crashes on valid expressions, doesn't compile correct closure syntax code or generates illegal byte code.

On the negative side there are some statements from Neal Gafter:

It's been nearly three months since the 0.15 draft, and it is now less than two weeks before the TL (Tools and Languages) final integration preceding openjdk7 feature complete. If you've made progress on the specification and implementation, we would very much appreciate it being shared with us. If not, perhaps we can help. If Oracle has decided that this feature is no longer important for JDK7, that would be good to know too. Whatever is happening, silence sends the wrong message.

A discussion between Neal Gafter and Jonathan Gibbons:

Great to see this, Maurizio! Unfortunately it arrives a week too late, and in the wrong repository, to be included in jdk7.

I notice that none of the tests show a variable of function type being converted to a SAM type. What are the plans there? Jonathan Gibbons' response: Since the published feature list for jdk7 and the published schedule for jdk7 would appear to be at odds, why do you always assume the schedule is correct? Neal Gafter's answer: Because I recall repeated discussion to the effect that the feature set would be adjusted based on their completion status with respect to the schedule.

Some people even question if the whole thing makes sense anymore and suggest moving to another language:

One starts to wonder, why not just move to Scala -- there's much more that needs to be added to Java in order to build a coherent combination of features around lambdas. And now these delays, which affect not just users of ParallelArray but everyone who wants to build neatly refactored, testable software in Java.

Seems like nobody's proposing to add declaration-site variance in Java => means FunctionN<T, ...> interfaces will not subtype the way they should. Nor is there specialization for primitives. (Scala's @specialized is broken for all but toy classes, but at least it's moving in the right direction)

No JVM-level recognition that an object is a closure, and can hence be eliminated, as it can be with Scala's closure elimination (if the HOF can also be inlined.) The JVM seems to add something like an unavoidable machine word access to every polymorphic call site, even if they are supposedly inline-cached and not megamorphic, even inside a loop. Result that I've seen is approximately a 2x slowdown on toy microbenchmarks like "sum an array of integers" if implemented with any form of closures other than something that can be @inline'd in Scala. (And even in Scala, most HOF's are virtual hence can't be inlined.) I for one would like to see usable inlining in a language that /encourages/ the use of closures in every for loop.

Conclusion

This is just a quick look at the whole problem going on and the quotes and statements are not exhaustive at all. At the moment people are still in the state of "Can closures really be done in Java and if yes, how should it be done and how might it look like?".

There is no simple "OK, we just add closures to Java over the weekend". Due to the interaction of some design mistakes like varargs as arrays, type erasure ... there are cases which just can't work. Finding all these small problems and deciding if they are fixable is quite hard.

In the end, there might be some surprises. I'm not sure what that surprise will be, but I guess it will be either:

• Closures won't get into Java 7 or
• Closures in Java 7 will be what Generics were in Java 5 (Buggy, complex stuff, which looks like it might work, but breaks apart as soon as you push things a bit further)

Personal opinion

I switched to Scala a long time ago. As long as Oracle doesn't do stupid things to the JVM, I don't care anymore. In the evolutionary process of the Java language mistakes were made, partly due to backward compatibility. This created an additional burden with every new change people tried to make.

Basically: Java works, but there will be no evolution of the language anymore. Every change people make increases the cost of making the next change, making changes in the future more and more unlikely. I don't believe that there will be any changes to the Java language after Java 7 apart from some small syntax improvements like project Coin.

Answer 3

http://java.dzone.com/news/closures-coming-java-7

Answer 4

The latest news is AFAIK still as of late Nov 2009 that closures will be in Java 7 in some form. Since this was given as the main reason for a significant delay in the release, it seems pretty unlikely that they'll drop it again.

Answer 5

There's been a whole lot of syntax and transparency related debating (particularly focusing on how hard to read a currying function with a particular syntax is, it seems like) going on on the lambda-dev mailing list, and there have been a couple draft proposal iterations from Sun, but I haven't seen much from them on that list in a while.

Answer 6

I'm at a release conference now and the speaker is saying closures are coming to Java 8.