Lucky Ball and Chain

Swing to get an application framework?

Maybe the problem with Swing development doesn't begin with squabbles over look-and-feels or lightweight rendering. Maybe it starts with:

public static void main (String[] args)

How are you supposed to get a desktop application out of that? "Oh," say the battle-weary Swing veterans, "there are a hundred ways to do it." Yeah, that's the problem: there are a hundred ways to do it. What's the difference between different approaches; what works better and what works worse? Do you build your GUI on the main thread and not worry about event-dispatch until you're done? How do you handle shutdown? Where do you get resources from? Heck, how is a host operating system supposed to know that this is an application? You're not seriously expecting the end user to open up a terminal window and type java -jar MySwingApp.jar, are you?

To some degree, the problem with "Swing applications" isn't about the "Swing" part, it's all about the "application" part. This hypothesis might explain why there isn't much traction behind SWT applications either, and why we're seeing more interest in "rich client platforms" based on Eclipse, NetBeans, etc. Of course, an important problem with the latter point is that, by and large, most desktop developers are not writing apps as sophisticated as the IDE's from which these platforms originated, so the hammer may be too large for a given developer's nail.

Hans Muller is taking a swing at the problem by introducing a simple framework for Swing applications, to manage resources, application life-cycle, and a few other topics, but without hiding Swing or trying to add another layer of complexity. He introduces it in his blog JSR 296 Bows - Swing Application Framework: "On Tuesday May 15th the JCP Executive Committee approved JSR 296, "Swing Application Framework". I'm the spec lead for JSR 296 and this is the JCP equivalent of a birth announcement. A rather long and meandering birth announcement, with a web started demo at the end."