Closures after all?
Apparently Mark Reinhold announced that closures would be added to JDK 7 at Devoxx today:
I can’t say what to make of that really. For years Sun has been saying that there is no consensus on closures and delayed the formation of a JSR or expert group on the subject despite having three proposals, all with prototypes.
Neal Gafter’s BGGA closures proposal is easily the most fully baked and has a fairly complete prototype and all of the necessary specification changes. I would have to guess that Mark’s announcement must be based primarily off the ideas in Neal’s work, but we’ll know more soon I guess.
After years of saying no, no, no to come back and announce a solution without any opportunity to enlist the community in what has been a previously contentious discussion seems destined to piss a lot of people off. This is the sort of thing people have been getting angry at Sun about for years (often wrongly imho but this won’t help). But maybe this is just an announcement that a JSR will be formed and not a declaration by fiat. It would be nice to have some more details.
It also throws into ever sharper relief the strange place we are with Java standardization. Sun has spent years moving the JDK into open source and more years improving the JCP process so there is a way to officially create a standard Java blessed by all. Yet, we are now at a point where the process for “Java 7 as a standard” is broken by all accounts, forever blocked by the Sun-Apache licensing issues. And instead of a process for creating a standard, Sun is mostly just doing whatever they want in the guise of the reference implementation “JDK 7″. That’s ok as an interim step but it assumes that at some point the Java 7 process will become unstuck, the community (via JCP) defines and approves a standard and has a say in where we are going with Java. If it doesn’t, then we’ve basically blown up the notion of a “standard” Java, which is the whole thing Sun’s been blabbing about for years.
To me, that would kill the biggest reason people use Java in the first place and that so many huge companies have bet their product lines and IT systems on it in the first place.
Hopefully, I’m reading too much into what at this point is just some tweets and a picture. I’ll try to keep posting updates here as I see them.
Links to info added as I see them:
- Geertjan Wielenga: Sounded to me like Mark Reinhold created a new syntax for Java closures on the flight from US to Belgium. He pretty much said that.
- Jean-Laurent Morlhon: from what I’ve understood, jdk7 is pushed to end of 2010, which should give enough time to include “lite” closures.
- Stephen Colebourne: Closures will probably be in JDK7, and they are very like FCM closures! The FCM spec: http://docs.google.com/Doc?id=ddhp95vd_0f7mcns.
- I talked to Bob Lee a bit at QCon and he thought it was possible that the extended timeline for JDK 7 may allow the ParallelArray work to come back in and make use of the new closure support. And that would indeed be a worthy inclusion in my book.
- Neal Gafter has updated the closure spec here v0.6a
- Starting to see some discussion of this on the Coin mailing list with some discussion of syntax and the spec.
- Comments at Hacker News
- Comments at Reddit
- Stephen Colebourne gives an in-depth overview
- Cay Horstmann gives some examples and commentary
- java.net has some analysis
- Helpful update from Reinier Zwitserloot from the Devoxx BOF
- Ted Neward drops some thoughts
- Neal Gafter clarifies in this thread that the 0.6a spec referenced above was written about two weeks before Devoxx, prompted by a discussion with Gosling about a compromise spec. He doesn’t know whether Mark read it or not.
Hi! My name is Alex Miller and I live in St. Louis. I write code for a living and currently work for 
Expect Sun to be actively working on closures for JDK 7. And they are simple closures (no non-local return, no control statements, no access to non-final variables).
Also, the syntax and semantocs Mark showed was modelled on the FCM proposal :-) http://docs.google.com/Doc?id=ddhp95vd_0f7mcns
Prediction: Don’t sweat Java 7. Java is a verbose, noisy language that will slowly die. The JVM will live on for a long time, but languages like Scala will make Java less and less attractive for new development.
@John.
The trouble is that with the JVM comes the Java standard library. This library, and most other Java libraries for that matter, is not built with closures in mind. This makes it clunky to interface with from languages that do have closures. Also, languages with closures must each define their own incompatible function types – some libraries even define their own incompatible function types. You can certainly mix ie. Google Collections, ParallelArray and Clojure in the same pot today, but it won’t be seamless.
But why being so negative if you don’t have the details? Wouldn’t it be better to be a bit more neutral until the situation is clear?
>>” The trouble is that with the JVM comes the Java standard library. This library, and most other Java libraries for that matter, is not built with closures in mind. ”
Well java.io was not designed with nonblocking IO in mind. What happened? We got java.nio.
Closure-aware libraries will unfold, just as Google-Collections, Guice, etc were created thanks to the presence of Generics.
What an unexpected twist. I want closures, but I am truly confused now. But so is Sun apparently.
Hopefully this is a sign of things to come … where Sun is able to freely innovate around Java without being shackled by the do-nothing JCP.
Agree with Daniel. I think your criticism Alex should be directly mainly at Google who have been holding up all kind of meaningful progress in Java (particularly on closures), while at the same time busily pushing out their own crap, and fragmenting the Java platform. Whether it’s Android, Go, Chrome OS, etc.
My concern is the fact that they are setting precedent with this and the modularity project to throw in non-JSR’d stuff in the pot with things under a JSR. It’s really no different than Microsoft “opening up” OOXML but including bits that prevent anyone other than them from having a viable implementation.
@Mike,
Neither Go nor Chrome OS run on the Java platform. J2ME fragmented the mobile space much more than Android could ever dream to. An cross-device Android-like app store doesn’t exist for J2ME because Sun let the operators fragment the platform.
Noop runs on the JVM and is by Google.
http://code.google.com/p/noop/
@Mike: At least Google is innovating and constantly pushing the state of the art. To come down to your own rhetoric, we don’t need no stinkin’ JCP to protect corporate interests and favor large and complex enterprise stacks.
Noop doesn’t actually exist enough to fragment anything.
@Daniel: noop is hardly relevant (yet). Right now it’s just a 20% project by a few google engineers
Adding closures to Java is starting to sound like reforming health care!
The way in which this has unfolded is certainly disappointing, but I am glad it’s happening.
What about inference? Without it closures seem pointless.
Amused by all this criticism of Google’s hidden menace. The real culprit is IBM, whose orchestration of Harmony has allowed them to trigger the obsessive idealism of Apache into crippling the JCP for them. If Sun does nothing everyone will criticise; if Sun does something it will have to bypass the JCP and people will criticise. No wonder IBM’s Mills and Smith were laughing yesterday. (http://briefingsdirectblog.blogspot.com/2009/11/ibm-feels-cozy-on-sidelines-as-oracle.html)
Maybe we get multi-line string literals after all too! :-)
I have to say that the FCM syntax really fits the Java syntax! :-)
I’ve just realised that the reason I hadn’t warmed to Closures in Java before now (the Java proposals and the C# lamdas) is that the proposals really made no attempt to look natural to the existing syntax. Even worse, many proposals really worked hard against one of Java’s foundamental property – Readability.
‘…instead of a process for creating a standard, Sun is mostly just doing whatever they want in the guise of the reference implementation “JDK 7″.’
Welcome to the world of Oracle!
Java is interesting again. Maybe there is hope that I won’t have to convert my half million lines of code to Scala after all. I really hope they keep at innovating aggressively.
My wish list:
traits / mixins
properties
less boilerplate
multiline string literals / here-documents
cleaner & more concise syntax around nullability than @Nullable and @NotNull
Hmm… who do I kill for this? Seriously, wtf?!
There are so many other proposals that have more consensus and are better for Java than closures. Why shove this down our throats now?
Gili,
Shove it down our throats? Seriously? If don’t understand closures then move to another language that doesn’t have them. You’ll be hard pressed finding one. Please amuse us and tell us the proposals that have more consensus.
Being the developer of the lambdaj project I am sure I am a bit biased, but I believe this situation is becoming truly ridiculous.
This proposal provides more or less the same set of features offered by lambdaj (actually lambdaj has also curry that seems missing in this spec). The only advantage i can see here is a nicer syntax.
But I took 3 days to develop closures in lambdaj, while (if everything will go as claimed and I am not sure of that) it will need about 3 years to have the same stuff in jdk7. Indeed I remember I am participating to discussion about closures since late 2007 and now they are telling us that we will have them in late 2010.
The elephant is going to give birth the mice.
Mario – lambdaj is great, but it is no substitute for a true closures implementation, and obviously can’t compete performance-wise since it depends on proxies.
Could the announcement be to distract attention from something else? Please the noisy crowd with one thing while taking away something else?
My guess would be modularisation. Has the development timeline blown out? Have they encountered some difficult problems?