JDK 7 Unexpectedly Gets “Simple” Closures, but is Pushed Back to End of 2010

Posted by Dionysios G. Synodinos on Nov 19, 2009

Sections

Process & Practices,

Architecture & Design,

Development

Topics

Language ,

Java ,

Change ,

Language Design

Tags

Language Features ,

Closures

During his Devoxx talk, Mark Reinhold has announced that JDK 7 will have Closures.  With the inclusion of this much debated feature, JDK 7 schedule will be extended until around September 2010.

Joseph D. Darcy, lead engineer of Project Coin, which aims to make small language changes for Java 7, has confirmed that the next version of the language will include some kind of “lightweight” Closures:

… JDK 7 will have closures, a to-be-developed from of closures smaller than BGGA, and that the JDK 7 schedule will also be extended until around September 2010.

Alex Miller who attended the talk points out that Sun has been negative about Closures although the community had produced 3 different proposals in the past:

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.

After the announcement at Devoxx, Neal Gafter who was a co-author for one of the three Closures proposals (BGGA, named after the initials of Bracha, Gafter, Gosling, and von der Ahé), has released a “simplified proposal”:

Changes in this revision

• The control invocation syntax has been moved to a separate specification.
• The term closure literal has been replaced by lambda expression.
• We overhauled the syntax for lambda expressions, borrowing loosely from Clang. There are now two forms of lambda expression: an expression lambda has a controlled expression, while a statement lambda has a controlled statement.
• The term closure object has been replaced by function object.
• The term closure conversion has been replaced by lambda conversion, with a separate block conversion for the control invocation syntax.
• Added new semantics for the return statement: it can now be used to return from a statement lambda.
• Renamed java.lang.Unreachable to java.lang.Nothing ala Scala.
• Removed support for the type name null. The previous version used null as a placeholder for an exception type when none can be thrown. The type Nothing now serves that purpose.
• Overhauled restricted. The concepts of restricted and unrestricted function types and closures have been removed. Now, all lambda expressions are restricted. The equivalent of the previous specification's unrestricted closure may be passed to a method by using the control invocation syntax.
• Added support for method references: We added support for treating a reference to a method as a function using a newly introduced token #. The syntax is borrowed from cross-references in javadoc and the FCM proposal.

This sudden change in plans for JDK 7 has made people like Fabrizio Giudici skeptic about the decision process:

I don't want to discuss whether it's a good or a bad thing (you know I think it's bad I suspend any judgment as I understand that the proposal is neither BGGA nor CICE, but something new). I'm only appalled that after a few weeks that the final word of Java 7 had been said with Project Coin (the famous final five or so), somebody changed his mind all of a sudden. What kind of decisional process is this?

Ah, I got it - it's tossing a coin, now I get where the project name came from. I fear Java 7 could be the most chaotical Java release ever - a very good idea if you want to kill it prematurely (as it there weren't already many other sources of entropy, such as the Oracle deal or the Jigsaw / OSGi debate).

Similarly Geertjan Wielenga thinks that the inclusion of Closures was a very unexpected development:

Great news and maybe best if no one asks too many questions about how that process ended up throwing up this solution! First, we have a whole bunch of proposals, all of which get lukewarm reception. Then, suddenly, like a bolt from the blue, we have "simple closures". (I wonder if any of the existing proposals are called "complex closures". Isn't simplicity the whole purpose of closures in the first place?) OK, the closures will be simple in the sense that there will be no non-local return, no control statements, and no access to non-final variables. Still, how was that decision made?

Cay Horstmann, provides several use cases for this new BGGA proposal, which is very similar to the FCM proposal:

We don't really know what exactly Sun intends to do. I simply analyzed the BGGA 0.6a proposal, which is presumably what BGGA is today. There is no denying that it looks a lot like FCM. No non-local returns. # for lambda. Since you need to annotate a mutated variable with @Shared when you capture it, perhaps people would think twice before writing

    foreach(@Shared String v : values) 
   		funcs.add( #() => v);

As Alex Miller mentions, the extension of the JDK schedule might make it possible for other features to make it into the release, like the the ParallelArray library which provides a functional style API for mapping, filtering, reducing over an array of Java objects:

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.

You can find more information about Closures and JDK 7 right here on InfoQ!

Dionysios G. Synodinos is a Web Engineer and a freelance consultant, focusing on Web technologies

1. Back to top

   I am not that distributed

   by Alex Miller

   I can personally attest that I did not actually attend the talk at Devoxx, as I am actually at QCon right now. I'm into distributed computing and all that but I am not myself yet distributed. :)
   
   Alex

   Reply

2. Back to top

   if they add some more features...

   by Robert Varga

   ... I wish they also added the final Exception - throws declaration improvement

   Reply

3. Back to top

   Where the bile blog when you need it?

   by William H

   I like Sun. Really I do. I might be in favour of adding closures to Java if they can find a formula that is less baroque then the original BGGA specification (and the new draft has already got rid of the distinction between "restricted" and "unrestricted" closures which is a good start). But what the hell is going on here?
   
   As a decision making process for one of the most important bits of technology around today this is an absolute disgrace. How is Sun deciding what does and does not go into Java 7? More to the point why is Sun deciding what does and doesn't go in to Java 7. The whole process is ludicrously opaque. Gilad Bracha, Neal Gafter, James Gosling, and Peter von der Ahé were apparently all in favour of adding closures to Java 7 but there wasn't enough "community support" (whatever that means) to do it so Sun dropped the idea. So what has happened since? Did the wind change direction? Was fiery Mars suddenly in the more orderly sign of Capricorn? Has Josh Bloch suddenly said "actually, you know what, I think this a good idea" and everyone sighs a sigh of relief and says "OK lets get on with it".
   
   The insane thing about all this is that Sun has a process, the JCP, which actually works pretty well. I know people like to bash the JCP, but, to misquote Winston Churchill, it’s the worst form of governance in the world accept for all those others that have been tried. For one thing needing to produce a spec, a reference implementation, and a test suite prevents the sorts of abuse that other standards bodies suffer(1), and yet when you know what you want to standardise things can get happen very quickly (as JSR-330 recently demonstrated). It has produced some amazingly good things (EE 6 for a start). But what? It isn’t good enough for Java 7 anymore since Java was open sourced? We can't use it because those nasty people at Apache might vote against the JSR and then where would be? We can't use it because Java is mine, mine do you hear and noone else can play with it (evil gloating laugh). We can't use it because we wanted to play with our toy one last time before Oracle buys us/we go under? What?
   
   ---------
   1: Microsoft Open Office XML, a "standard" which noone, including Microsoft has actually implemented, I'm thinking of you here

   Reply

4. Back to top

   Good news

   by Thom Nichols

   I don't have an opinion on the decision-making process (plenty of other ppl seem to have that covered) but I am glad to see closures get included sooner rather than later.
   
   Hopefully the extended release date will also allow them to apply closures to the various JDK APIs where they make sense (e.g. collection traversal/mapping/filtering, resource management, etc.) Inclusion of fork-join in the JDK7 should be a given too since it will have the necessary closure support.

   Reply

5. Back to top

   Re: Where the bile blog when you need it?

   by Matt Giacomini

   I would like to add a +1 to every word of this comment.

   Reply

6. Back to top

   That's ridiculous

   by Mario Fusco

   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.

   Reply

7. Back to top

   Re: Where the bile blog when you need it?

   by Cameron Purdy

   Two comments:
   
   1. In the presentation, IIRC he specifically said that the Parallel Arrays stuff would be omitted (because it adds a few billion classes to the JDK).
   
   2. He said in the presentation that the closure implementation is going into JDK 7 (I assume "Open JDK", which is an open source project); he did not know whether or not it would make it into Java 7 (which is controlled by the JCP, and thus not available for direct control by Sun).
   
   Peace,
   
   Cameron Purdy | Oracle Coherence
   coherence.oracle.com/

   Reply

8. Back to top

   Facing the wall of closure Java (difficult) adoption

   by Dominique De Vito

   As I have written in Facing the wall of closure Java (difficult) adoption, the problem is: adopting closures is one step, adopting type inference is another step, and adopting both, as the same time, while it would alleviate the closure burden, could be too much enough for some developers.
   Or, to say things differently, making one step (closure adoption) does not let developers happy (due to different closure opinions) and making two steps in one move (closure+type inference adoption) would alleviate the closure burden, would be a good closure/type match , but it is too much enough for some developers.
   So, the problem remains.
   
   I have no preference for a closure proposition. And that's a pb when no proposition has the lead.
   But if something coul/would be introduced into JDK 7 for making a step towards closure, I prefer to enable automatic method autoboxing into interface(implementation) as stated in Next JDK wishlist-3: a first step towards closure into Java.
   
   Dominique
   www.jroller.com/dmdevito

   Reply

9. Back to top

   Hard to please

   by Eirik Maus

   In the spring, lots of people were angry because the closures went out of the scope for java 7. Now they are angry because it's back in. I guess some people are hard to please.

   Reply

10. Back to top

    Re: Hard to please

    by Mario Fusco

    I guess some people just would like to see a clear direction in the development of the language's features instead of this unbearable mess.

    Reply

• Older >