Skip to main content

DEVOXX Surprise: Out of Nowhere, Closures in JDK 7!

Posted by editor on November 19, 2009 at 5:29 AM PST

Conferences typically include some surprise announcements, usually by corporate sponsors of the conference. But a great many developers were astonished by the unexpected news from DEVOXX '09 that JDK 7 will include closures. Here's an image (resized smaller) that I found in Alex Miller's post Closures after all?



Mark Reinhold at Devoxx: Closures in JDK 7

Alex isn't at DEVOXX, but I think he speaks for a great many developers in his opening commentary:

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.

Fabrizio Giudici is appalled by the apparent coin flip nature of the emergence of closure in JDK 7:

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?

Fabrizio goes on to say "I fear Java 7 could be the most chaotical Java release ever..."

Remi Forax considers Lite closure in JDK 7 to be good news, but he hopes "such closure will be on top of JSR 292 method handle."

Geertjan Wielenga noted (and wondered):

A second interesting, yet odd, thing was the surprise announcement out of nowhere that JDK 7 is going to have closures after all. 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?

As for me -- I see people whose expertise I respect on both sides of the issue. With respect to the language, I find closures to be acceptable as a programing option. But, with respect to development of the type I've done throughout most of my career, I'd consider the implementation of closures in high-availability operational systems overall a negative. Why? Because I believe that this type of programming makes code more complex to the uninitiated than it has to be. It may simplify things for the original developer, but when that person departs the organization, and someone else has to modify or enhance that code -- that becomes a real problem!

I've worked for a long time in an environment where we're building back-end infrastructure that has to be rock-solid and enduring. The development team historically has had a greater turnover than the software. When Joe, Alexei, Marina, and now Peter have worked on the same piece of code, it's problemmatic if the code is not readily understandable. I as manager have a budget for each needed mod or enhancement.

In all of my experience working in languages where, in essence, functions can be passed as arguments -- I've found that the code is difficult to work with once a new developer receives the assignment to maintain or enhance the code. This is a loss of efficiency -- not something most companies can afford during our present (or any?) economic times.

I can see how making closures available can make development more efficient during the design and initial implementation phase for new projects. But, overall, I think for a language like Java which has enormous amounts of operational high-end infrastructural code already in existence, the formal addition of closures poses a danger. The original developers of the legacy code may have moved on. What if a new developer improperly wraps a legacy function, effectively making it a closure, to simplify the task at hand -- might that create potential new security risks? In addition, of course, to making the code difficult to understand for the novice developer who takes over the maintenance of that code 18 months from now, after our clever closure function developer has moved on...

I suppose that making closures more formally and readily possible in Java isn't necessarily a problem. You can say it's just another programming option. We all like more "options" when we go shopping, right? But, in the back-end high-availability operational infrastructure realm that I work in (which, I think, is clearly the most important realm, since if that fails, all client apps are useless), as development manager and architect in this environment, I'll demand that my developers completely shun their use.

The bigger question people are asking right now, though, is: how did closures suddenly become a to-be-implemented part of JDK 7? Where was the community process in this? Where was the closing open debate? This announcement at DEVOXX surprised pretty much everyone!


In Java Today, Alex Miller comments on the surprise JDK 7 announcement at Devoxx, in Closures after all?

Apparently Mark Reinhold announced that closures would be added to JDK 7 at Devoxx today... 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. Neal Gafter's BGGA closures proposal is easily the most fully baked and has a fairly complete prototype and all of the necessary specification changes. I would have to guess that Mark's announcement must be based primarily off the ideas in Neal's work, but we'll know more soon I guess...

Danny Coward posted Devoxx 09: JDK 7, Java EE 6, JavaFX, Java Store and more:

The href="http://blogs.sun.com/dannycoward/">Janitor is here at href="http://www.devoxx.com/display/DV09/Home">Devoxx, just href="http://ec.europa.eu/commission_barroso/kroes/index_en.html">down
the road from Neelie Kroes !  Her
influence
was on show at the href="http://devoxx.com/display/DV09/Java%2C+the+Platform+for+the+Future">Oracle
keynote, which began with a
legal disclaimer saying something about href="http://en.wikipedia.org/wiki/Forward-looking_statement">forward
looking statements about products not being indicative of anything.
One has to be sympathetic as the href="http://www.reuters.com/article/mergersNews/idUSLH59514320091117">commission's
wheels grind on,
but it was a bit like hearing that the tenor has a href="http://twitter.com/hhund/statuses/5823243779">sore throat
before
the opera starts. Happily, Roberto
and Ludo were more
melodious, announcing the href="http://java.sun.com/javaee/technologies/javaee6.jsp">imminent
December 10th release date for Java EE 6 and Glassfish v3 and a
demo of deploy-on-save in Eclipse (it could href="http://www.indicthreads.com/5079/netbeans-6-8-becomes-the-first-ide-with-support-for-entire-javaee-6-spec/">equally
have been in NetBeans),
re-deploying href="http://weblogs.java.net/blog/286/2008/11/14/ease-development-java-ee-6-platform">deployment
descriptor-free servlets and EJBs to href="https://glassfish.dev.java.net/">Glassfish v3 in about a
second. Adobe gave an
engaging
keynote, and although the Janitor didn't love the smell of all the
multistep
automagical conversion to massage an app developed in the flash
tool into something allowed to run on the iPhone
(pretty sure href="http://www.wired.com/gadgetlab/2008/11/adobe-flash-on/">Apple
doesn't either), the image-to-widget tool in Adobe Catalyst href="http://twitter.com/Shonzilla/statuses/5824304313">demoed very
well. Something to think
about for the href="http://javafx.com/docs/gettingstarted/production_suite/">JavaFX
Production Suite...

Geerjan Wielenga posted his notes on Devoxx Day 3: Conference Day 1:

The conference proper started today. Up until now, there had been a lot of very long sessions, lasting 3 hours or so, i.e., university sessions. Now, not only did the sessions become shorter (i.e., more presentation-like and less lecture-like), but several big guns from the world of programming (e.g., James Gosling, as well as Oracle guys) turned up.

Before continuing, let me reveal that I am the Devoxx conference for one reason only: the El-Menoufiya JUG in Egypt gave me their ticket, since none of their members could make it. Hamada Zahera and the rest of the guys there: you rock and I am honored to be an honorary Egyptian. (Here's a pic of the whole group, me included.) ...


In today's Weblogs, Fabrizio Giudici finds that Now I've understood the meaning of "coin" in Project Coin:

It seems that at Devoxx it has been announced that closures will make their way in Java 7, after all. I don't want to discuss whether it's a good or a bad thing (you know I think it's bad). 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...

Remi Forax comments on Lite closure in JDK7:

It seems that "lite" closure will be in JDK7. I really don't care about the surface syntax but I hope that the runtime of such closure will be on top of JSR 292 method handle...

Felipe Gaucho is Testing PDF files with Canoo Webtest and Maven2:

This week I received one of that lovely and tricky tasks: to
learn Canoo
webtest
, test it and prove its usefulness to the project in three days -
convincing the managers that it should be part of the project. The goal
of the project is to produce a finance report with ~200 pages and that
report should be validated through a zero-errors acceptance
tests. Several tools were considered, including Selenium and others, but
Canoo was choosen due to its PDF test features...


In the Forums, ciaodiego wonders about import world wfs from wonderland 0.4 to 0.5: "hi, i've create a world wfs in wonderland 0.4 called universita-wfs.
how i can import the old word in wonderland 0.5? there is a tutorial? ..."

treeniap has a Need to change LWUIT Designer screen size: "Hi, I've got LWUIT the lwuit resource editor to act as a kind of wsywig layout editor for my designers. It works great but i really need to change the default resolutions available in the theme preview. How can I add screen sizes..."

bernard_horan posted Simplified Chinese Locale... please test: "Thanks to Qingjiang Yuan, we now have a Simplified Chinese locale (zh_CN). So, if you are a Chinese-speaking developer currently using one of the other Locales, please take a moment to switch to the new Locale and test it out. Let us know of any issues..."


Our current Spotlight is Josh Marinacci's new JavaFX open source Project MaiTai: "What is MaiTai? MaiTai is an open source tool for building interactive artwork. You create interesting sketches by wiring different blocks together with lines. There are blocks to produce graphics, process mouse and keyboard inputs, connect to webservices, and perform complex graphical transformations. The end result is limited only by your imagination. MaiTai can export a Java Webstart application or a QuickTime movie..."


The new java.net Poll asks Do you belong to a Java User Group? The poll will run through Thursday.


Our Feature Articles lead off with Sanjay Dasgupta's in-depth article Simplify Native Code Access with JNA. We're also featuring Eric Siegelberg's Using a Service Delegate to Avoid MVC Controller Bloat, which describes how to maintain separation of concerns and avoid MVC controller bloat through the use of service delegates. And, our latest Java Tech guest column is Marina Kamahele's "Transparent" Panel - Mixing Heavyweight and Lightweight Components.


The latest Java Mobility Podcast is Java Mobile Podcast 90: Augmented Reality: Excerpts from the JavaOne 2009 Augmented Reality session with Kenneth Andersson and Erik Hellman of Sony Ericsson.


Current and upcoming Java Events:

Registered users can submit event listings for the java.net Events Page using our events submission form. All submissions go through an editorial review before being posted to the site.


Archives and Subscriptions: This blog is delivered weekdays as the Java Today RSS feed. Also, once this page is no longer featured as the front page of java.net it will be archived along with other past issues in the java.net Archive.

-- Kevin Farnham

O'Reilly Media

AttachmentSize
DevoxxClosures_med.jpg76.9 KB
Related Topics >>

Comments

Bad programmers can always write bad code

I'm currently maintaining/improving some code that was written in the early days of Java (1.2 or 1.3 or something), and it's appalling. So many badly written, needlessly written classes, methods, and functions it hurts. So much copy/pasted code too...

Point is, when the code was written there were way less options than there are today (both in terms of JDK features and 3rd-party libraries like Spring, Hibernate, etc), but the code is still very hard to extend/maintain.

Would adding closures have allowed the developer to write even worse code? Probably, but they were a bad developer to start with.

If you have good developers, ones who are willing to listen to company policy, and who can write code that can be understood in 18 months time, then is it actually necessary to ban them from using closures? Surely you're able to trust them enough to let them decide when closures are and are not acceptable? And if they can't write code that will be readable in 18 months time (without closures), then what the hell are you doing letting them anywhere near your backend infrastructure projects in the first place?

So the language is now a little more complex, but I feel the complexity added by closures is tiny compared to the existing complexity of the Java Enterprise Ecosystem. You can't say 'We shouldn't add this new feature because it will make it easier for bad developers to write bad code'. Bad developers can write bad code no matter what you do. The only way to stop bad developers writing bad code is to remove their keyboard.

programmers and complications

All very good points, ipsi.

Part of my "difficult to maintain" point is that even good programmers can apply what in the future will be seen as bad practices when they adopt a new technology or new language features. Best practices are learned by the developer community over time. So, any time something new is introduced, it's probably going to be misused by some developers (even good ones), until "best practices" for using that technology or language element emerge.

You're right, though. Languages progress. In the enterprise back-end environment, we typically stick with the tried-and-true, because high availability is the measure of our success. Hence, my statement that if I, as a manager, had to set a policy on use of closures, my initial statement would be: don't. But, that policy might change once best closure practices emerged and were commonly understood.

Right now, almost no one even knows what the exact nature of the addition of closures will be. That's remarkable, after such a long public process of winnowing down the list of possibilities for JDK 7 to a final few -- a list in which closures were not present!

True enough, though I don't

True enough, though I don't think 'misuse' is the most appropriate term. On the other hand, I can't exactly think of a better one...

Well yes, that's definitely true. But it's not just that high availability is your measure of success (trivial, provided no one uses it :P), it's the potentially catastrophic effects of a bug that really motivate the slow, incremental, 'wait for everyone else to find the bugs' approach to adopting all the 'cool new toys'. Well, that's what I would expect, at any rate.

Yep, that seems to be a major hot topic right now. Don't imagine anyone's really thinking about best practices so much as either 'Why didn't you choose my favourite?!', or 'Where's the consultation?' (or both). The second one concerns me more (especially since I didn't have a favourite), and I reckon it's a more important topic, in the long run, than the exact implementation of closures.