JDK 7 Unexpectedly Gets “Simple” Closures, but is Pushed Back to End of 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
Nothingnow 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 badI 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 writingforeach(@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.
I am not that distributed
if they add some more features...
Where the bile blog when you need it?
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
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.
Re: Where the bile blog when you need it?
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.
Re: Where the bile blog when you need it?
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).
Cameron Purdy | Oracle Coherence
Facing the wall of closure Java (difficult) adoption
Dominique De Vito
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.
Hard to please
Mike Amundsen May 29, 2015
Ben Linders May 28, 2015