Closures in Java 7 - does a new era start for the language?

Published on
22,205 Points
13 Endorsements
Last Modified:
Community Pick
Java had always been an easily readable and understandable language.  Some relatively recent changes in the language seem to be changing this pretty fast, and anyone that had not seen any Java code for the last 5 years will possibly have issues understanding some of the code that is written nowadays.  And one of the new features of Java 7 seems to be adding even more to the confusion.

Java 5: Generics

When Sun announced their plans to include the Generics in Java 5, a lot of the developers were not exactly happy, even though they were not a foreign concept for most of the people that had started with other languages before the creation of Java. This change added a lot of complexity to the language.  But they were part of the evolution of Java, so most developers accepted them, and found good usage for them (is there anyone missing the casting or conversion that was needed every time when an object had to be retrieved from a collection?).  But, at the same time, expressions like
<T extends Object & Comparable<? super T>> T Collections.max(Collection<? extends T>) { ... }

Open in new window

prove that even if Generics are generally a great idea and can be quite useful, they also open the door for a lot of issues. And that's not even close to the most complicated expressions that can be done. Most of the experienced Java developers can understand this line but that does not make it readable or easy to understand.

Java 6: The calm times

After the release of Generics, things in Java started to move quite nicely--the new versions started fixing the problematic areas without any major language changing events, and even though the discussions for all types of changes and revisions never stopped, no one expected anything to happen for a while, especially after the official announcement at the Devoxx conference, at the end of 2008, that the closures will not be part of Java 7 (which was expected to be released in early 2010).  This was pushing them for the Java 8 release (if not a later one), and was allowing the language to get through the bigger issues first (the garbage collector, the memory management, the non-modularity of the JDK to mention just a few), before adding another major component.

Java 7: Closures are back on the table

Then came the announcement that the release of JDK 7 is pushed for September 2010, and possibly later.  And just a few months ago came the latest news:  on the same conference as in 2008, but a year later, the closures were officially announced as the newest addition to Java 7.

Java had always had partial closures - the anonymous inner classes were very close in meaning to what closures are doing in other languages.  For example, the simple action of adding a listener to a button required a fully implemented inner class:
   new ActionListener() { 
      public void actionPerformed(ActionEvent e) { 

Open in new window

According to one of the new proposals for closures, this code will be simplified:
jButton.addActionListener(#(ActionEvent e) doSomething());

Open in new window

This looks like an improvement of the readability...at least at first glance.  Unfortunately, this is pretty much the only case in which the closures will make the code easier to read, and it is replacing an existing form of closures... Would you try to guess what either of these codes do:
{ => void } el = object#action();

Open in new window

{ String => void } el = { Object object => System.out.println(object); };

Open in new window

I admit that I needed quite a lot of time to get my head around the concept, and to be able to read these codes, even if I can write in Lisp (which is one of the sources for this new syntax).  Just remembering how I thought that Generics were complicated makes me smile now.

All the examples above are using the BGGA closures proposal syntax. The second proposal is the FCM one. Technically it is still unclear which one will be the final one even though all indications seem to be pointing to the first one, even if the declared base is the second one (with some parts excluded - you can look at the resources at the bottom of the article for more information).  Both proposals are close--the drafts have a lot of similarities, and some of the bigger differences had already been ruled out as not becoming a part of JDK 7.

What will end up in the language is anyone's guess at this point, but I suspect that the codes above will end up working when JDK 7 gets published.  Until then, it is time to sit down, wait and watch the news coming from Oracle.  Sooner or later the specifications will get closed, and we all will need to get used to the new syntax when it shows up with Java 7--as we did with Generics back in Java 5.  And I suspect that I will write more than one article about the closures when the things get a little more clearer.


If you are interested in the topic (or if this article made you curious), here is a small list of additional reading materials:
Stephen Colebourne's Weblog - and you might want to look closely at the table that he had compiled for the differences between the different proposals

Enjoy this complimentary article view.

Get unlimited access to our entire library of technical procedures, guides, and tutorials written by certified industry professionals.

Get 7 days free
Click here to view the full article

Using this article for work? Experts Exchange can benefit your whole team.

Learn More
Experts Exchange is a tech solutions provider where users receive personalized tech help from vetted certified professionals. These industry professionals also write and publish relevant articles on our site.
Ask questions about what you read
If you have a question about something within an article, you can receive help directly from the article author. Experts Exchange article authors are available to answer questions and further the discussion.
Learn from the best.