Mitch Pronschinske is the Lead Research Analyst at DZone. Researching and compiling content for DZone's research guides is his primary job. He likes to make his own ringtones, watches cartoons/anime, enjoys card and board games, and plays the accordion. Mitch is a DZone Zone Leader and has posted 2576 posts at DZone. You can read more from them at their website. View Full User Profile

Update on Closures Coming to Java 7

11.19.2009
| 26504 views |
  • submit to reddit

It was announced yesterday that closures would be added to JDK 7.  Mark Reinhold made the announcement at the Devoxx conference.  Before today, Sun could not reach a consensus on the inclusion of closures in JDK 7.  Three proposals for closures were submitted to Sun over the last few years.  With the JDK 7 schedule extended to September 2010, Reinhold seems to think that now is the time to bring closures to Java.

A few more details about the closures announcement for Java 7 surfaced today.  According to Stephen Colebourne's blog, Mark Reinhold's Devoxx announcement indicated that "JDK 7 closures will not have control-invocation statements as a goal, nor will it have non-local returns.  He [Reinhold] also indicated that access to non-final variables was unlikely.  Beyond this, there wasn't much detail on semantics, nor do I believe that there has been much consideration of semantics yet."

Here's a strawman syntax for closures that Mark Reinhold wrote on his plane ride to the conference:

  // function expressions
#(int i, String s) {
System.println.out(s);
return i + s.length();
}

// function expressions
#(int i, String s) (i + s.length())

// function types
#int(int, String)



The syntax resembles the FCM closure proposal, but Reinhold made it clear that he was using FCM as an example and not endorsing it.  Joseph Darcy from Sun said the closures would be "Smaller than BGGA."  A few weeks before the conference, Neal Gafter, a co-author of the BGGA closure proposal, wrote a simple specification for closures in Java.

Comments

Armin Ehrenreich replied on Sat, 2009/11/21 - 12:16pm in response to: Mario Fusco

Closures in Java are a political problem not a technological one. Many computer scientists create new languages with a wide variety of features. The question is, which of them fit together in a mainstream language, not how advanced the particular feature is. This was the big mistake with the wildcards in the generics specification where someone completely lost the feeling what is a level-headed solution for the problem of making container more type safe. The same would have been true for the full BGGA proposal. So I think the current proposal for closures is a very good compromise.

Mario Fusco replied on Sat, 2009/11/21 - 5:51pm in response to: Armin Ehrenreich

I am not questioning if this is a good compromise or not. I am saying that is crazy that they took 2 years to find an agreement on it (I am still not sure they find it) and now they are saying they need another year to implement it.

Liam Knox replied on Sat, 2009/11/21 - 7:49pm in response to: Mario Fusco

I think the limitations of lamdaj are understated. That you cannot use this with final classes is a big downside and the risk that someone could make a breaking change without notcing based on zero compilation safe guards is large. Also that you would potentially have to compromize security for the use of an API is not great.

Closures should be part of the language.

Mario Fusco replied on Sun, 2009/11/22 - 6:11am in response to: Liam Knox

Of course lambdaj has some limitations imposed by the java specs. Those limitations have never been hidden and I hope they are quite well documented. So it is just your choice if they are bearable for you or not. 

Anyway I did not want to focus the discussion on my library. Sorry if I went OT. As I stated somewhere else lambdaj is just an attempt to have in Java a feature that I missed (and still miss) in the language. As a fan of functional programming I would be very glad if we could have real closures built in the language. And at that point I will be happy to throw away lambdaj.

What I meant to underline is something different. Let me slightly reframe the current situation in order to clarify my point of view. Two years ago, you said to your employer that you were going to add a new fantastic feature to your product. Then you spent (wasted) the following 2 years discussing with your development team about different proposals and evaluating their consequences. At the end of this 2 endless years you went again to your employer saying that you need another year to implement a "simplified" version of that feature. I bet at this point of my hypothetical situation your boss was running through the rooms of your office like an headless chicken screaming loudly some non-repeatable words.

Being one of the about 5,000,000 of Java developers in the world I suppose I am one of the employers (or customers, it is more or less the same in this context) of people who work to define the next specs of the language. And at the moment my only feeling is just that I wanna scream.

Silvio Bierman replied on Sun, 2009/11/22 - 12:32pm in response to: Liam Knox

I consider Java generics a perfect example that supports my view. On its own generics are a great language asset but Java generics are a very poor implementation of the feature. Many people who have tried to use them for anything but the most trivial constructs have agree on this. This was mainly caused by the desire to make it backwards compatible and blend in with the standard library. Unfortunately the lack of reified generic makes it even impossible to fix them in any JVM language, which is why even in Scala they are not as powerfull as they could be. Annotations are a beast on their own. I really dislike them and consider them a duck tape feaure to sort of tie stuff together. Whether the rt.jar libraries are predominant or not depends on the situation. I suspect that 98+ percent of existing Java code heavily depends on them but you may live in a different Java world. But even then adoption by libraries is just one thing. If you study any language designed around closures (and Scala is a good example here) you will see that closures are supported by other language constructs (important examples being support for currying and a more relaxed syntax for providing parameters in function calls). It is the combination of closures and such features that allow the creation of powerfull construct using closures. Lacking those closures are little more than fancy syntax sugar for nested classes.

Liam Knox replied on Sun, 2009/11/22 - 8:13pm in response to: Silvio Bierman

I agree on the downsides of the chosen Generics implementation, though this is not really addressing your own statement. Generics were introduced with success to the Java language. Their upside is larger than their limitations. They did not need to be introduced at day one. They have benefitted many developers

I do not really understand your own personal problem with annotations. They are a brilliant way or addressing certain concerns, such as cross cutting, exposure, for example JMX.

That you brand closures as little more than syntatic sugar based on that they were not introduced from day one is absurd. Look at the fork-join proposal, with and without closures.

Liam Knox replied on Sun, 2009/11/22 - 8:24pm in response to: Mario Fusco

I can appreciate your frustration, I share it too. I am just happy with the proposal to introduce them in 7 and not later. Given the latency between releases this news is very welcome.

Sadly I work in an industry where the scenarios you mention are not all together that uncommon.

Silvio Bierman replied on Mon, 2009/11/23 - 7:06am in response to: Liam Knox

It is obvious that once closures in any form are available new additions can benefit from them, I never denied that. I just said that many existing things will start to look crooked or at least funny. Why are these Swing event handlers all written using nested classes? Why do we need java.io.FileFilter? I want to reiterate that I do not think the closure proposal is bad on its own. I just think closures are so compelling they will drastically change the way new Java code is written by new programmers. It will make lots of existing constructs redundant therefore making the language as a whole less logical and minimal and could introduce doubt on how to go ahead in teams working on existing code bases. Simplicity and lack of overly redundant alternatives used to be strong points of the Java language. On a side point it strikes me that you tend to consider opinions that differ from your own ignorant, comedy or nonsense. Why the defensiveness? It hardly comes across as open minded.

Liam Knox replied on Mon, 2009/11/23 - 7:27pm in response to: Silvio Bierman

I do consider some of your comments very strange. For example the syntactic sugar reference. Did you even look at the fork-join proposal ? I also disagree it will make a lot of existing constructs irrelevant. You have only mentioned inner or anonymous classes. But at the end of the day this is just a pattern of using an interface as Closure-like construct. The fact is the intereface construct is no less invalid or powerfull.

Silvio Bierman replied on Mon, 2009/11/23 - 9:39pm in response to: Liam Knox

Actually, the closure proposal partially removes the type safety of interfaces from the language. The compiler will substitute a closures for any interface having only a single method with the same signature. This is an example of trying too hard to blend in closures with existing libraries. I would have preferred to preserve the distinction. I consider support for currying close to essential for the ease of use of closures. Also, I think having type inference makes them a lot easier to work with and read. I would have loved any closure support in Java when I took up the language in the late 90s. Now I think it is too late. Yes, I looked at the fork-join proposal. It is very smart but I find the FCM version hardly pleasing to the Java eye. But then again, tastes may differ.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.