People Get Ready
Are you ready to start using closures?
If there's one thing we've learned from the generics argument, it's that when language changes are being discussed, you pretty much have to take a side. If you don't like a library, you can just choose not to use it, but with new syntax, sooner or later you're going to be expected to use, or at least maintain it. The problem with the generics discussion is that too much of it happened after generics were added to the language, when it was too late for those who thought them overkill to really do anything about it... and simply ignoring them turned out not to be an option.
That's why I think that the closures proposal for JDK 7 is getting a closer look -- you might never plan to write one, but if closures become part of the language, you'll have to at least understand them, so better that they make sense and deliver some substantive value, right?
The question is, will closures provide enough value to merit all the millions of Java developers around the world having to learn a new syntax?
Mikael Grev has kicked off an extensive discussion on JavaLobby with his JDK 7-oriented argument Why Closures in Dolphin is a Bad Idea, which we feature in the Java Today section. He starts out by proving that he knows what closures are and then wonders whether there are sufficient use-cases for closures that can't already be handled by existing tools, like anonymous inner classes. He also questions whether it's really worth the cost of making developers learn a new syntax, and whether it makes sense to try to closure-ify core Java API's like the Collections framework that weren't designed to use closures. He ends his case with a warning:
I think that closures are the rocket scientist's answer to a problem that can be solved by a plumber and a carpenter. If closures would have been here from the beginning I would have loved it but that is not the case and there's nothing we can do about that now. C++ went down the power over simplicity road and never came back.
Also in Java Today, the Java EE 5 SDK Update 2 and Java Application Platform SDK Update 2 have just been released, to capitalize on last week's release of Java SE 6. The SDK includes the GlassFish-based Sun Java System Application Server Platform Edition 9.0 Update 1 Patch 1, samples, blueprints, API documentation, a portlet container, and more. The "platform" download also includes NetBeans IDE 5.5 with NetBeans Enterprise Pack 5.5. For more information, Inderjeet Singh describes the contents and performance improvements of this release in a recent blog.
Kelly O'Hair has posted a JDK6 Build Cheat Sheet, which actually applies to builds of both JDK 6 and JDK 7, and in part to JDK 5. He shows how to use build flags to control the build and just include the features you want, as well as how to build just Java SE and not the VM, or just HotSpot and not the VM.
Reminder: there are just a few days left to send in your pictures of Duke's holiday for our annual year-end roundup. Please send pictures by Tuesday.