Posted by joshy
on November 10, 2003 at 8:40 AM PST
Joshua discusses how Swing (and by extension, Java desktop applications) have failed and what we as a community can do about the situation.
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
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
- 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.
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.