Skip to main content

Complicated Game

Posted by editor on August 28, 2006 at 7:57 AM PDT


Could closures be generics all over again?

I was listening to the Java Posse this morning, and their choice of topics was interesting: they started with last week's white-hot back-and-forth over the idea of adding closures to the Java language in JDK 7, and then got into the much-linked weblog entry Java 5 Language changes were a bad idea.

Near the end of the latter discussion, they talked about what they thought were three typical stages of adoption of new language features, which go something like this:

  1. This is great!
  2. No, wait, this sucks!
  3. You know, this is pretty good after all.

Accurate? Maybe. I'm not sure if we had people changing their mind on generics and autoboxing so much as we had a lot of people not really paying attention to them until they were part of the language and everyone suddenly had to care. After all, even if you don't use generics, you might be responsible for someone else's code that does. And from this, we saw the backlash against some of these JDK 5 features, not just now in Shai's weblog, but last year in a number of places (for example, see last October 19th's Daily Editor's Blog Broken Hearts Are For...).

Yet the Posse say that by embracing generics, they've turned up a number of bugs that they might not have found otherwise. So they've moved on to the third stage of this progression.

Now, they didn't make this comparison explicit, but it's not hard at all to imagine being at step one of this process again, this time with closures. A lot of people (myself included) are excited about the potential to eliminate some ugly inner-class anti-patterns with the use of closures. The Posse also wondered aloud if the implicit state-save of a closure would then lead to support for continuations, which would be remarkable. But there are some already expressing a concern with the syntax of the Java closure proposal, and others asking if this is truly worth adding to the language, with the requisite increase in complexity of adding another programming metaphor.

Will we get closures in JDK 7? Will I be linking to bloggers who say that closures suck, only to then have everyone agree later that they're actually really useful and more than syntactic sugar?


The Java Today section kicks off with a new resource to foster understanding and discussion of the Java closures proposal. The wiki page Closures Syntax in Java 7 collects resources from around the web related to the new proposal to bring closures to the Java language in JDK 7. The page links to the original PDF proposal, blogs, and running discussions on the proposal, and also hosts its own "Discussion on Syntax" section for further debate over the specifics of the proposal.

The ninety-first issue of the JavaTools Community Newsletter is online, collecting tool-related news from around the web, welcoming two new projects to the community (Enuke and Source Code Mania), and featuring a tip of the hat to the Java Posse podcast.

Ed Burnette points out a surprising combination of projects in EoS - Eclipse on Swing: "In what has to be one of the most cleverly named projects of all time, EoS (named after Eos, the Greek goddess of the dawn) promises to bring Eclipse to Sun's Swing platform. EoS is the result of a collaboration between Dieter Krachtus and SWTSwing developer Chris Deckers. A download is available, but it's currently more a proof of concept than a usable system."


Back to the closures discussion Tom Ball asks Are Closures Just Delegates? in today's Weblogs. "Back in the pre-JDK 1.1 days delegates, or bound method references, were considered and rejected by the Java language designers in favor of inner classes. What has changed so much that these reasons no longer apply?"

In Swing made easy with genesis, Michael Nascimento Santos writes:
"In the beginning, developing with Swing was a pain. It was hard to assemble an interface and even harder to program it. Then, Matisse appeared, and as more people could design their interface, more and more asked, 'hey, but how can I make it work for real now'? The answer is in genesis."

Finally, Roberto Chinnici has a handy introduction to
Logging in Phobos:
"Phobos now includes a logging API. Besides regular application use, logging (in the form of tracing) can be used to learn about the framework."


As SwingX works towards their first real release, some tricky issues need to get resolved. In today's Forums, rbair seeks opinions on a proposed problem with JXPanel and Translucency:
"We had an internal review today that covered the JXPanel and ran into some issues with regards to translucency. Currently, there is an 'alpha' property on the JXPanel which you can use to specify how translucent the panel and its contents should be. The "paint" method of JXPanel sets an AlphaComposite on the Graphics used for painting, causing JXPanel and all components on it to be translucent. However, what happens if a child component is painted? Normally, that paint request only goes up the tree if the child component is not opaque, otherwise only the child component is painted. However, since JXPanel needs to set the AlphaComposite, it is necessary that painting start at the JXPanel, not at the child component."

And who's worried about licensing the JDK? As robilad points out in
Re: Copyleft, GPL, and Java,
"the implementation already ships under half a dozen different licenses, and the impact on the end user (i.e. the average Java developer) is minimal. Adding the DLJ as an option, for example, helped make Java deployment easier for many circumstances, but didn't matter to many Java developers who're happily using Java on Windows. Adding this new licensing option has not taken anything away from the rights of users of deveopers, and I don't see Sun doing that with an open source license for the JDK, either, whichever license they pick."


News editor Steve Mallett notes that it seems to be "App Framework Day!" from a look at today's java.net
News Headlines
:

Registered users can submit news items for the href="http://today.java.net/today/news/">java.net News Page using our
news submission
form
. All submissions go through an editorial review before being
posted to the site. You can also subscribe to the href="http://today.java.net/pub/q/news_rss?x-ver=1.0">java.net News RSS
feed.


Current and upcoming Java
Events
:

Registered users can submit event listings for the href="http://www.java.net/events">java.net Events Page using our href="http://today.java.net/cs/user/create/e">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 href="http://today.java.net/today/archive/">java.net Archive.

Could closures be generics all over again?