Josh On Design

I've been writing Swing apps for a long time and despite the speed and API improvements I don't think it's gotten better. After reading

Chris's latest blog about it I decided that I really need to chime in. Most Swing apps, and there are sadly few, suck. I mean really suck. They are the suckiest bunch of sucks that ever sucked! And here's why:

Swing apps are slow to build. Building a Swing GUI takes time because you have to do it programmatically. No GUI builder can do it reliably. While the extra day you spend writing layout code may not be much in the life of a six month project, it still matters. The GUI needs to go through many iterations, preferably as early in the project as possible. If it takes hours to make changes then the project probably will not slip behind due to the extra development time. Instead the extra iterations just won't be made, resulting in an inferior product.

Swing layout managers suck. GridBagLayout is particularly bad, though it's better than all the others. Layout is an inherently visual task that needs visual tools. I wouldn't layout a magazine with a text file, I'd use Quark. Why shouldn't I have a quality visual builder for my Swing app?

Swing apps are hard to maintain. Since there's no standard place to put everything a maintenance coder will have to make heavy use of the search function to figure out how the app goes together and where to fix things.

Swing is too powerful. In terms of extensibility it's very powerful, but the complex API gets in the way of simple tasks, something that turns off new or infrequent programmers. Swing is great as a theoretical toolkit, taking advantage of modern UI theory: factories, renderers, MVC, event handling, and internationalization. (though I wish the rendering and event handling was more virtualized). But this is really overkill for many day to day tasks.

No native features. Each platform has interesting native features that may or may not have analogues on other platforms. Java was originally designed with cross-platform wrappers around everything for two reasons: to ease the life of developers (you don't have to code something twice) and to stop people from writing Windows only Java apps. I agreed at the time but I now thing this reasoning is flawed. Given a choice between more coding to conditionally use a native features versus not having access to the feature at all, I'll take the extra work. (note: Apple has done a pretty good job here, but we need more.)

Swing apps have a bad history. The early applications gave Swing a bad reputation that still lives on today.

So what can we do about it? How do we counteract all of Swing's current and historical flaws?

From Sun I only want two things:

• Fix the bugs. There are some longstanding Swing bugs that Sun seems to refuse to fix. When working on some code to print out Swing components I ran across a bug that has be documented on the Java forums and Sun's buglist since 1.2!!! These simply have to be fixed. Good apps need a stable platform. This also means fixing the issues with the native look and feels that Sun is responsible for. I understand that 1.5 will help a lot

• Make something better than Metal. Suck it up. Pay a graphic designer for one year to develop a better default L&F. Something innovative and comprehensive. Something that will wow everyone when you release Java 1.6. You'll make it back just in free press.

From the community we need more:

• One single open source and extremely well documented package of reusable Swing components. They should each work independently and must be documented clearly enough that someone can drop in a jar and init a class after 60 seconds of reading. The package should include all of the common extensions that people keep reimplementing. Something like the Jakarta-commons for Swing. Something to handle the boring stuff so that we can all move on to more interesting things
• A structured way of building Swing apps. Something like Struts where each concern (aspect?) has it's own special place to be stored and manipulated. How do you organize your layout, workflow, validation, intz'ed text, and hooks to the BL? Should you subclass to make frames or use factory code? We need a set of best practices and then a framework to implement them.
• a standard cross-tool representation of a GUI that is not Java code. Something that can be moved in and out of different IDEs and build tools. Probably an XML representation or maybe serialized Swing objects.
• A really good visual screen builder. All it does is layout out widgets and ensure that you never ever have to deal with layout managers at the code level again. This builds on top of the previous request.
• VB for Swing. An integrated IDE for prototyping and developing throwaway scripts. It's for non-pros and for pros when they want something quick and dirty. An editor for the little things. Throw up some widgets and pop out an EXE. It's really more like Visio than a real IDE, but completely invaluable for building mockups ASAP. This builds on top of the previous request.
• An intermediate API. Maybe we need a simpler API on top of Swing? A new set of wrapper components which hide a lot of the complexity. Hell, half of the work could be done by just conditionally hiding 3/4 of the API from the Javadocs.
• More articles and one good book. More articles on writing polished GUIs and better components. Stuff on actual UI design and usability. And maybe just one really good O'Reilly book on everything it takes to make a Swing app shippable.
• Competition Sun should sponsor a well publicized competition at least once a year. The only requirement is that each application uses Swing and has a free downloadable demo.

I believe in Swing. I really think it's the best toolkit for writing robust cross-platform applications. However, if we don't do something to jumpstart it's growth then it'll die along with the dinosaurs: big, powerful, and unable to keep up.