Skip to main content

Shake It Up

Posted by editor on February 1, 2007 at 7:04 AM PST

So just what do we mean by closures anyways?

It serves the platform well to have a vigorous debate now about what should go into JDK 7 -- to dig through the pro's and con's of closures, a new properties syntax, a modular JDK, etc. -- and thereby prioritize what should go in. If one of these is a dud with the community, better to know now than after JDK 7 comes out.

Closures came in a very close third in the recent poll What one feature would you most like to see in JDK 7, and was the highest-ranking language change. It's probably gotten the most discussion over the last few months, and has the advantage of already being backed with a concreted, if still-evolving, proposed specification, authored by some of the top luminaries in the Java world.

But... just what are we talking about? Outside of the specification itself, can we speak consistently about what closures are, are not, and how they differ from anonymous inner classes? Neal Gafter has stepped in to provide A Definition of Closures, which traces closures back to their origins in Scheme and Smalltalk, and then makes the case for what they would be in Java:

We are now considering adding closures to Java, a significantly more complex language than either Scheme or Smalltalk. We're not considering them because they seem like a neat idea, or because they worked out well in other languages, or because we're bored. Rather we're considering them: because of the power and flexibility they will add to the programmer's arsenal; because of the improved readability we expect from programs that use closures instead of the existing alternatives; and because of a number of other recently proposed language extensions that will be unnecessary if closures are added. In order to get the full power of closures, they should capture all lexically scoped semantic language constructs.

The last part of Neal's blog makes the case that anonymous inner classes don't cut it, that they can be made to do the same things as closures, but not cleanly or effectively. Take a look and decide for yourself if this helps make the case for putting closures in the next version of Java SE.

Also in Java Today,
the JSR-296 Swing Application Framework prototype implementation is a small set of Java classes that simplify building desktop applications. The prototype provides infrastructure that's common to most desktop applications: application lifecycle, support for managing and loading resources, support for defining, managing, and binding Actions, and persistent session state. "The intended audience for this snapshot is experienced Swing developers with a moderately high tolerance for pain."

Issue 276 of the NetBeans Community Newsletter is out, featuring NetBeans Visual Web Pack 5.5 ML, NetBeans Mobility Pack for CDC 5.5 with Demo, Intel Endorsement of NetBeans, New Hands-On Labs: Java SE 6, Web Services Security, a Cool Tip on Tabs, How to Create a Movie Player, Using the Ajax Map Viewer Component, High-level Introduction to NetBeans IDE & the Community and much more...

In today's Weblogs.
James Gosling announces that is alive! (again):
" (the javadoc website designed for communal collaborative translation) is finally back up again after a couple of days being dead. It took so long because (tragically) I have a Real Job."