Why SWT?
Originally posted 2004-05-20 12:44:34
I recently attended my first Java Users’ Group (JUG) meeting. My interest in belonging to a JUG has coincided with a renaissance in the previously moribund local JUG, so I couldn’t have timed things better.
In this meeting, we discussed ideas for future meeting topics. Most suggested topics revolved aound J2EE, which covers most of what I do, but I offered to do a presentation on SWT and JFace in conjunction with the release of The Definitive Guide to SWT and JFace. Heads agreeably nodded and a few \”yeses\” bubbled up. Then, however, one member, apparently only just restraining himself, wondered aloud why SWT even existed, that Swing rendered SWT completely superfluous, and SWT should disappear. He spoke in clipped tones and measured syllables, revealing his contempt for and hostility toward SWT. I frantically scanned the room for the nearest exit.
Actually, I smiled, and the moment passed. I wondered, though: why should we have SWT? Besides the fact that I want lots of people to buy my book, I mean 🙂 My next few blog entries will address this question.
In his book Russell Rules, Bill Russell, the great Celtics center who won 11 NBA championships in 13 years, tells about when his grandson asked him if he was as good as Michael Jordan. After Russell stopped laughing, he told his grandson that he’d asked the wrong question. The real question was: Was Michael Jordan as good as Bill Russell? Similarly, asking why we should have SWT represents the wrong question. Why shouldn’t we have SWT?
The reason most often propounded for eliminating SWT claims that Java must have a solitary GUI API or library to have any hope of growth, or at least survival. Fragmentation, supposedly, weakens Java’s chances for desktop development, and only a unified front can possibly catapult Java onto users’ desktops. Since Swing claims seniority, and since it’s Sun’s offering and therefore \”pure,\” it should continue as the one true Java GUI API–or so the reasoning goes. Why, however, should Java limit itself to one GUI API or library? What other environment limits itself to one GUI API? Certainly none of the major environments adhere to this limit. Windows, the established desktop leader, offers too many APIs/libraries spread across too many languages to enumerate, and this has been a help, not a hindrance, for Windows’ growth. For example, you can write a Windows GUI program using these APIs or libraries (among others):
- Win32
- MFC
- OWL
- wxWidgets
- Windows Forms
- Qt
- ATL
Notice I haven’t even mentioned any of the drag-and-drop \”APIs\” like Visual Basic or PowerBuilder. The Unices (into which I lump Solaris, Linux, et al.) have (among others):
- Motif
- Qt
- GTK
- Tcl/Tk
Heck, even Mac OS X, the bastion of closed systems, has Cocoa, Carbon, and Classic.
Choice confuses users, but developers hail from a different breed: they’re (usually) more intelligent than average. They can handle choice. They thrive on choice. Programmers love to learn different things, try new technologies, exercise their minds in new ways. More APIs mean more approaches, more possibilities, more tacks to sail in the sea of programming.
On a final note, I’ve noticed that most people miss the affront to Sun of the Eclipse name. When I mention that an eclipse blocks the sun, I see eyes widen with understanding. Perhaps this helps explain the hostility that Swing developers feel toward anything SWT.