Still celebrating National IT Professionals Day with 3 months of free Premium Membership. Use Code ITDAY17


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

Published on
21,822 Points
13 Endorsements
Last Modified:
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

Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
LVL 93

Expert Comment

by:Patrick Matthews
Passes one crucial test of a good article: it was clear enough that even this non-Java guy was able to understand some of the issues involved.

Nice stuff!


LVL 60

Expert Comment

by:Kevin Cross

Very nice coverage.  I like how you did an evolution from Java 5 - 7 too, as Patrick indicated it makes it clear and easy to read no matter your Java level.

Thanks and can't wait to see more of your articles!
Voted "Yes" above.

LVL 20

Author Comment

I probably will end up doing some highly technical ones (targetting Java developers) also as soon as the JSRs are done and it is clear what happens... ("Closures made easy" series maybe?)

At the moment - I had been reading and playing with these lately and this format made the most sense - the closures are really tied to the generics (at least in terms of changing the language radically). It is all another story that I wish they had cleaned Generics before they had started on this but we don't get what we want most of the cases. :)
The top UI technologies you need to be aware of

An important part of the job as a front-end developer is to stay up to date and in contact with new tools, trends and workflows. That’s why you cannot miss this upcoming webinar to explore the latest trends in UI technologies!

LVL 40

Expert Comment

Hi Venabili,

I hope Java does a better job of implementing Generics than C# does. As a C++ programmer, accustomed to templates and generic programming, I cringe every time I think about how utterly poor C# Generics are in comparison.

When you refer to closures, I presume you mean lexical closures like you can fine in Perl and Lua? If so I am a great supporter of these constructs as well as Lamba functions and it is always a source of frustration to me that they are not supported in C++ (natively at least). fortunately, the next version of C++ is supposed to include these constructs too and I am very much looking forward to using them

With regards to the article, it's great... very informative and just like matthewspatrick, even as a non-Java person, I was able to follow it just fine.

I voted "yes" -- I hope that means we'll be getting more from you :)

Best regards,

LVL 20

Author Comment

Actually they did Generics badly (or better to say - they left way too many options open very fast)... and as it looks like won't clean them. Yes, there are great things there that I love but thefull thing just leads to confusions...

Hopefully the Closures (yes, these ones plus some additions although almost all of them were removed from the initial versions - they had been discussed for way too many years and I really do not see a reason to have them in Java - I know the concept, I use it in other languages but in Java? ) will be a bit better implemented. But not holding my breath really.

I believe that C++ is also at the same stage as Java - they are working on a proposal for integrating these into the language. I do not think that they had closed the syntax either so let's see which language will make them stranger? :)
LVL 40

Expert Comment

Yeah, C++03 is still in the ratification stage. It's possible -- but unlikely -- these things may get dropped still. They dropped support for "concepts" at the last moment, which was a huge disappointment to people like me who do a lot of meta-template programming.

Anyway, thanks for your thoughts and feedback Venabili, it's a hugely interesting article and I enjoyed reading it.

Featured Post

Free Tool: SSL Checker

Scans your site and returns information about your SSL implementation and certificate. Helpful for debugging and validating your SSL configuration.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

Join & Write a Comment

Viewers learn about the scanner class in this video and are introduced to receiving user input for their programs. Additionally, objects, conditional statements, and loops are used to help reinforce the concepts. Introduce Scanner class: Importing…
Viewers will learn about the different types of variables in Java and how to declare them. Decide the type of variable desired: Put the keyword corresponding to the type of variable in front of the variable name: Use the equal sign to assign a v…
Other articles by this author
Suggested Courses

Keep in touch with Experts Exchange

Tech news and trends delivered to your inbox every month