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!
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...
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.) ...
My Devoxx university session yesterday was packed, which was awesome! It was 3 hours of hard-core JavaFX knowledge, and almost everyone stayed for the duration. Aaron Houston got a great shot of the venue (more on the Java Champions site). I posted my slides on SlideShare, so check it out when you get a chance. Special thanks to my co-authors, Jim, Weiqi, and Dean for help with the content.
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...
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...
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..."
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.
Previous Topic
