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:


27 Responses to “Closures after all?”
  1. 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 :-)

  2. John Goodsen says:

    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.

  3. Chris Vest says:

    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.

  4. 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?

  5. Sakuraba says:

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

  6. Casper Bang says:

    What an unexpected twist. I want closures, but I am truly confused now. But so is Sun apparently.

  7. Daniel says:

    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.

  8. Mike says:

    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.

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

  10. @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.

  11. Daniel says:

    Noop runs on the JVM and is by Google.

  12. Casper Bang says:

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

  13. Logan says:

    Noop doesn’t actually exist enough to fragment anything.

  14. Anonymous says:

    @Daniel: noop is hardly relevant (yet). Right now it’s just a 20% project by a few google engineers

  15. Anonymous says:

    Adding closures to Java is starting to sound like reforming health care!

  16. Josh says:

    The way in which this has unfolded is certainly disappointing, but I am glad it’s happening.

  17. Anonymous says:

    What about inference? Without it closures seem pointless.

  18. The Contrarian says:

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

  19. Anonymous says:

    Maybe we get multi-line string literals after all too! :-)

  20. Tasos Zervos says:

    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.

  21. Anonymous says:

    ‘…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!

  22. Daniel says:

    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
    less boilerplate
    multiline string literals / here-documents
    cleaner & more concise syntax around nullability than @Nullable and @NotNull

  23. Gili says:

    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?

  24. javajoe says:


    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.

  25. Mario Fusco says:

    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.

  26. Josh says:

    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.

  27. Paranoid says:

    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?