Update on Closures Coming to Java 7

We Recommend These Resources

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

Collin Fagan replied on Wed, 2009/11/18 - 5:47pm

Are you messing with me? Did somone hack your account? The "early reports" link just points to the FCM proposal. This just sounds too good to be true.

Mitch Pronschinske replied on Wed, 2009/11/18 - 6:11pm in response to: Collin Fagan

You can see the visual evidence here.

Silvio Bierman replied on Wed, 2009/11/18 - 8:08pm

After "Scala coming to Java" I consider Java language changes redundant. We have moved all our Java production code to legacy status and have rewritten the frameworks that are essential for new code in Scala. During this process I have become convinced that only a completely new language AND a completely new standard library can make high level features like closures and generics (and in the case of Scala pattern matching) reach their full potential and take development to a new level. A new but "as binary compatible as possible" language like Scala creates a much better transition path out of legacy Java than any language addition can offer, especially because of the clear and absolute distinction between "old" and "new" code.

Collin Fagan replied on Wed, 2009/11/18 - 9:11pm in response to:

Ok, well then, cool. I played with FCM a while back just to see what the method literals were like. It was very cool.

Ryan De Laplante replied on Thu, 2009/11/19 - 8:53am

When will people realize that the majority of Java programmers aren't nearly as dissatisfied with the language as functional programmers seem to think? Give me NIO2, properties, a better date & time API, multi catch, the "elvis operator", USB & Serial ports on all OS's, and Java EE 6 instead. Hopefully once Oracle takes over Sun they will have the money and manpower to increase the pace of enhancement to the Java language. Since JDK7's release date has been pushed way out, maybe they can finally include these kinds of useful features.

Sven Reimers replied on Thu, 2009/11/19 - 1:25am

Having visited the BOF I can tell you that the syntax is just looks like FCM but FCM is not the basis for closures in Java 7. This comes directly from Mark Reinhold. I think the idea is , if I got Mark right, to take BGGA find a better syntax and just use function literals, function types and extension methods. So no control abstraction etc.

Alex Miller replied on Thu, 2009/11/19 - 2:12am

You can find some more info here. The syntax is FCM-ish but it's simpler than either FCM or BGGA. Neal Gafter has written up a quick spec.

Felipe Gaúcho replied on Thu, 2009/11/19 - 3:26am

@Ryan de Laplante: I completely agree.. too much buzz around "agile" revolutions and at the end of the day everyone keeps using Java, everyday better, everyday faster ...

Eugene Kisly replied on Thu, 2009/11/19 - 4:03am

That's really super cool :)

Armin Ehrenreich replied on Thu, 2009/11/19 - 4:08am

A suggestion for the syntax: Please make it to resemble what is proposed for C (and Objective-C). This would be more Java-like than using #, as many syntactical aspects of Java follow C and it would result in easy to understand code (as I know from Objective-C):

int variable = 10;
int (^nameOfClosure)(int) = ^(int argument) { return argument * variable; };

or when separating declaration and definition:

int (^exampleClosure)(int);
exampleClosure = ^(int argument) {
return argument * 12;
};

Liam Knox replied on Thu, 2009/11/19 - 4:48am in response to: Silvio Bierman

This is some of the most ignorant comments I have ever read. To say that changes to the Java language are redudent is pure comedy. Look at how many systems are written, and continue to be developed in Java. That figure is astronomically larger than any metric of Scala usage, and will be for many years to come. Big companys dont simply dump one technology in favor of another

Look at the history of other language usage, for example C++ or even Corba, in the real world and you will see its not just question of picking up the next 'great' language and starting again. It is often slightly more technically and politically complex than you infer

Closures will help Java developers although there is controvesy. I personally believe it is excellent news.

Karl Peterbauer replied on Thu, 2009/11/19 - 6:34am in response to: Liam Knox

+1. Good news for Javaland, no matter which syntax they finally pick.

With several thousands lines of Java code to maintain the next years, I never understood those cynical "Why don't you switch to Scala/Groovy/SomeOtherJVMBaseLanguage?" arguments.

Silvio Bierman replied on Thu, 2009/11/19 - 11:24am in response to: Liam Knox

That is your opinion. I am not saying Java is in any way redundant. The opposite is true, it is the most important workhorse language at this time, also for my own company. I am just saying that I see no point in changing the language, just like I think it makes little sense to change C++. Legacy systems need to be maintained and that will also involve writing new code. The language as it is is more than equipped for that. I do think that Java (the language) is becoming less and less relevant for new projects. That is not just personal opinion but I see it in my work as an architecture advisor for companies starting development of new software products. A couple of years ago they mostly leaned either to .NET (yes, I know that is not a language) or Java (with a slight advantage for .NET) but the last year I have seen few new Java projects. .NET is still going strong but Java seems to be replaced more and more by other languages for the JVM like JRuby and Groovy. In these cases Java is still considered but then as a workhorse language for the performance critical (less interesting/appealing) parts of the systems. The JVM is not loosing ground, Java is. My personal preference for Scala has little to do with this, I am not yet convinced it is a language for everyone so I am just using that in my own company. Instead of evolving Java, however, I think the JVM platform is better served with a new language that does not carry the burden of Java's legacy. Java generics are gross, the closure proposal is no more than the best we can get considering the circumstances and annotations are a monstrous attempt to fix something that is broken beyond repair. I am afraid an extended Java will not prove to be a very attractive option for the coming generations of developers.

Armin Ehrenreich replied on Thu, 2009/11/19 - 12:20pm in response to: Silvio Bierman

Not that I do not like Scala (although I heavily dislike C#) but the claiming that Java looses ground is not backed up by any data I can find:
http://www.indeed.com/jobtrends?q=Java%2C+C%23%2C+Scala%2C+Ruby&l=

Ryan De Laplante replied on Thu, 2009/11/19 - 12:51pm in response to: Armin Ehrenreich

Change the C# to .NET in your trend, and it shows .NET overtaking Java in 2005

http://www.indeed.com/jobtrends?q=Java%2C+.NET%2C+Scala%2C+Ruby&l=

I was a bit surprised to see this

Karl Peterbauer replied on Thu, 2009/11/19 - 1:28pm in response to: Silvio Bierman

@Silvio Biermann: Considerung annotations "a monstrous attempt to fix something that is broken beyond repair" is obviously a very emotional, very subjective opinion.I have a lot of old Java code in the fields which has been refactored successfully from 1.4-style to generics and annotations, and I have to maintain this code for many years to come (which is not a bad thing, since it's a proof that the code is not too bad). From this perspective, Java with closures is a much more attractive alternative for me than a fossilized Java without closures. Since you prefer other languages anyway you should respect this point of view.

GeekyCoder coder replied on Thu, 2009/11/19 - 2:27pm

There are many good valid points either in freezing Java or adding 'compelling' feature to Java language.

I like to give my point of view too.

I support the idea that Java as a language need to evolve by adding 'marketable' and 'useful' feature. Although freezing Java does not make it any less popular in near future since there are already huge investment in Java-written software, Java language need to have good 'attractive' feature to continuously entice new programmers and retain developers to build Java application. If change is inevitable, why does that not apply to programming language as well ? Beside, it is also in the best interest for companies that bet on Java technology for their business like Oracle, IBM, to continously make Java as attractive development language since a greal deal of their software are written in Java-only language, and will need Java programmer to maintain and enhance them. Moreover, if these companies are continue to use Java for their future project and new product, why then not improve Java to leverage on existing skill and experience ? After all, at the end of the day, what matter most is application get developed and programmers are happy to use and to exploit Java's feature.

Moreover Java to some is also both a passion and testbed for language innovation, and by improving the Java language, it also make for more interesting Java-derivative language (eg Groovy), . Perhaps it is the hope that Java still has promising life and innovation ahead in term of language feature that spurt more attractive language, library and framework. For example, library and framework are updated to exploit Generic, var-arg, Annotation, and the same will happen for Closure.

Eventually language will be overtaken by another better and popular language but if the language's life can still be prolonged by adding marketable feature, then why not ? If Java becomes marketable and popular, the programmer too will become marketable and in demand too. I hardly believe that Java will become the future Cobol as long as it continue to evolve with 'marketable' feature.

Let nature takes its course on Java but Java itself should not standstill to await its fate.

My wish-list for Java7 => G-String / Multiline string, closure

GeekyCoder coder replied on Thu, 2009/11/19 - 2:42pm

Why do we not want Java language to evolve when other alternate languages (eg Groovy, Scala, Fantom, JRuby) are continuously evolve with interesting and marketable features ? To say that Java should stay stagnant for reliability purposes , and that other languages can be used for Java's lackof feature (eg closure) are quite ironic because what make those latter languages anymore reliable with continuous change ?

Armin Ehrenreich replied on Thu, 2009/11/19 - 3:13pm in response to: Ryan De Laplante

But when you look at the actual job offers you see that now you have VB.net and C# jobs combined. That is the sum of two large languages and many admin jobs that have to know .NET without being programmers whereas Java is only 1 language.

Liam Knox replied on Thu, 2009/11/19 - 8:49pm in response to: Silvio Bierman

I think your views are somewhat odd and certainly not shared among the majority of developers, Java or otherwise. There is always advantages in evolving a language if the evolutionary step adds value. If you do believe Closures are a good idea then clearly there addition has the potential of improve the lives of hundreds of thousands of developers and millions of applications. That is the main point.

I would also say thay both Generics and Annotations have done this too for Java.

If you think that Closures add less value, i.e. by way of complexity, then clearly you would advise otherwise. Presumably as you like Scala you like Closures. Again, you have to think real world though. Yes it would be great to pick up Scala and use it everywhere from now, but that is not going to happen and preventing Java improvement based on this premis is plain wrong.

Look how evolution works interms of iteration and mutation, small step, big step you should get the general idea. Software languages have synergy to this.

Chris Knoll replied on Fri, 2009/11/20 - 10:19am

Can we please boot the people that are comming up with these stupidly terse synatx ideas?

In the old days, it was nice...you could read the code naturally and it made sense.

It started with the : operator....would 'foreach' have been such a problem? But it's the 'extends' keyword in other languages.

Now we have this #. Isn't that a way to mark a line a comment?

why's it so hard to type:

function x(int y,string z);

If they want to save characters, how about we rewrite the whole laugnage syntax...let's start with variable declarations...here's how we can map it out

int = .

string = $

bool = ?

float = %

double = %%

new = +

Think of all the typing savings!

. x = 4;

$ y = "Love the savings!"

/sarcasm

Someone tell me...WHY does java additions need to look like objective-C? It didn't start out that way, and making the new things model some other language just makes the whole thing look like a hodgepodge of disjointed ideas. It's like we have the wrong decision makers at the helm...

Neal Gafter replied on Fri, 2009/11/20 - 12:02pm

Actually, I wrote the specification a couple of weeks ago, before the conference, for an email conversation with Gosling. Reinhold's announcement was a complete surprise to me.

Silvio Bierman replied on Fri, 2009/11/20 - 12:50pm in response to: Liam Knox

Regarding programming languages quite the opposite seems to be true. Languages have come, sometimes dominated in specific areas and subsequently slowly vanished. Language evolutions have rarely had any influence on that process. A language like Cobol is a perfect example. It is far from dead and is still used for legacy system maintenance and evolution. But is has by long been surpassed by other languages when it comes to developing new systems. Attempts to modernize the language had no effect at all. An at that time considered superior language like Algol68 (which I was "raised" with) never gained any ground and perhaps Scala never will as well. I think closures are a great language feature. But they can thrive only if the language and its standard library have been designed around them. As a language add-on they will not fit in at all with the existing language features and the standard library, at least for existing code bases. Naturally, an improved Java can help developers of new systems in Java. I merely said that I am not interested in using Java for new systems since I think there are better alternatives for the JVM offering only advantages over Java while retaining the advantages of the JVM itself. I think that is the strength of the .NET platform. MS has focussed on the platform instead of trying to push one single language as the one and only truth. The JVM has the same potential but I feel it has always been treated by Sun as an afterthought that was only there to facilitate Java the WORE language. They where very late to the game with Groovy when other initiatives had already been developed. Sadly nobody ever created a VB-like language (with the tools) for the JVM. In the line of what another poster said I would prefer focus on strengthening the JVM as a platform. We need better cross platform support for stuff like 3D, audio and video. We need JVM improvements for tail recursion optimization, better support for dynamic languages and reified generics. If some dandy Java language features slip in along the way I will be the last to complain. In the long run I predict the JVM will outlive any individual language that runs on it. That is, if the JVM will be able to maintain its dominant position. It got there thanks to Java but I think now it's time we focus on the JVM instead of the language(s). Another poster said that many sysadmins are required to know stuff about the .NET runtime environment. Sadly I never encounter admins who know anything about the JVM apart from the fact that it is required for running Java programs.

Rogerio Liesenfeld replied on Fri, 2009/11/20 - 4:17pm in response to: Armin Ehrenreich

You've never seen the TIOBE index then?

Personally, my hopes lie with JavaFX Script. Scala has no chance in the long term, IMO...

cowwoc replied on Fri, 2009/11/20 - 11:22pm

Chris Knol is completely right.

Readability should come first!

Liam Knox replied on Sat, 2009/11/21 - 6:05am in response to: Silvio Bierman

But they can thrive only if the language and its standard library have been designed around them

is absolute nonsense. This has been couter proven by the addition of Annotations and Generics to the language. Also the predominant librarys are now not the ones bundled in rt.jar, but in the opensource world like Spring, Google-collections, etc, etc. If these players adopt closures, which I am sure they will, we will see far simpler and more powerfull librarys. I would also say the success of Scala is largely dependent on how the opensource community adopts it, so far I havent been impressed.

Armin Ehrenreich replied on Sat, 2009/11/21 - 5:27am in response to: Rogerio Liesenfeld

But this index is hardly (whatever it measures) a good argument for introducing advanced language features. More the other way around, as good old C and PHP are the kids of the block there.

Armin Ehrenreich replied on Sat, 2009/11/21 - 6:19am in response to: Chris Knoll

why's it so hard to type:
function x(int y,string z);

or maybe a keyword block instead of # which really looks like a comment.

Joerg Wassmer replied on Sat, 2009/11/21 - 7:56am

I fully agree to Chris Knoll's comment. The proposed syntax isn't Java-like. One of the biggest advantages of Java is the readability of the sourcecode. Now that cryptic closure syntax, that is a step back. I am very familiar with maintaining code in C, Delphi and Java. In a large codebase. The most importent thing for a good codebase is its readability. That's why I don't like C. Delphi is awfull at all. Scala is spaghetti code by design. I love Java, but will I keep loving it with such language additions?

Mario Fusco replied on Sat, 2009/11/21 - 10:08am

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.