Swing, AWT, and SWT

I have heard many people discuss these GUI toolkits as though they are equal competitors. I’d like to state unequivocally that they are not. Use Swing. Use Swing.

Of course, what kind of advice would that be without backing it up with a long post? Without further ado, here’s details on the pros and cons of all three Java GUI toolkits, and how they compare.

AWT vs. Swing

This is one of those presumably old debates. It used to be relevant around ten years ago, but Swing and Java have both so drastically improved that there’s no reason to use AWT. Furthermore, the debate is somewhat moot since Swing is heavily based on AWT; a more apt title would be AWT vs. AWT with Swing-like sprinkles on top.

In fact, you can think of Swing as the successor to AWT rather than a competing toolkit. If you trace the class hierarchy of most Swing classes, you’ll find it has a AWT ancestor. Swing uses vast swaths of AWT functionality, so much that it’s safe to say Swing is built on top of AWT.

Heavyweight components have a native counterpart; lightweight components do not

Of course, both provide a set of ready-to-use GUI components, like buttons, menus, etc. The discussion of which toolkit to use usually means which set of GUI components to use, since the underlying framework in AWT is used directly by Swing.

It’s been commonly said that AWT’s components are “heavyweight” and Swing’s are “lightweight.” These terms do not necessarily mean either component is worse in terms of functionality or performance. They refer to whether a GUI component is “backed” by a native peer. You can think of a native peer as the “real” GUI component that the host platform would use normally. In other words, a native peer is the C or C++ class that you’d instantiate directly if you were programming in C/C++ exclusively.

The problem with this idea is that native peers necessarily vary between host platforms. Since AWT bases its functionality off these hosts, it is forced to the lowest common denominator of capability. This meant that relatively common components, like tables and trees, could not be included in AWT.

It should be mentioned that neither toolkit actually has a monopoly on either lightweight or heavyweight components. AWT is capable of creating lightweight components, and Swing must use heavyweight components when creating top-level components.

Swing has no native peers; it is pure Java

The limitations of AWT’s functionality led directly to Swing. Swing’s components are lightweight; they are pure Java and do not rely on the host platform. Swing’s components are therefore consistent in behavior across platforms.

Java’s aim is to be seamless, both to the developer and the end-user. The appearance of components should ordinarily look like the host platform’s. To solve this, Swing separated the behavior of components from their appearance. The appearance side is broken into many libraries, each implementing a different look and feel for each host platform.

Swing is, roughly, a superset of AWT

Swing is hardly written from scratch. Many components in Swings deliberately mirror their AWT counterparts. Other features use AWT classes directly. For example, all Swing components are derived from some AWT class, typically java.awt.Component.

Swing lies on top of AWT, adding a richness that the constraints of AWT did not allow. This freedom gives Swing the existing power of AWT with the flexibility to extend it as the designers and developers see fit. AWT’s components, on the other hand, are bound by the slow evolution of various host platforms.

There is no debate; use Swing

People usually see these two frameworks and imagine that there must be some choice to be made. After all, both are still around. However, there is no real choice. Swing is the successor to AWT. The reason AWT is still mentioned is because Swing uses an incredible amount of it.

It should be mentioned that there are no great performance gains anymore between AWT and Swing. Initially, AWT was respectably faster than Swing since native peers do allow performance gains in some cases. However, it’s been awhile since those times, and Swing and its companion libraries (like Java2D) have been optimized heavily. Performance is not a reason to use AWT over Swing.

SWT vs. Swing

Discussing Java toolkits should necessarily include this third-party toolkit, known as SWT or Standard Widget Toolkit. Popularized by its use in Eclipse, SWT can be thought of as a rewritten AWT, but with a Swing-fallback. SWT uses native peers if available but can fall back to pure Java components if a certain platform doesn’t support the features required. The reason for this extends beyond simple performance gains; SWT exposes a far greater amount of low-level functionality to the programmer. The intention is to allow a highly customizable interface for developers.

SWT is not standard

SWT has many forces working against it. For one, its name belies the fact that it’s not standard. SWT is a third-party toolkit not available on a vanilla Java install, nor is it necessarily compatible wherever Java can be run. Since it relies heavily on native integration, a SWT library must be written specifically for each native platform. The problem caused with this isn’t that you’ll be out of luck trying to run it on your machine (SWT already has most OS’s covered). Since SWT intentionally exposes alot of low-level capability, the experience may not be symmetric across these platforms. Reconciling these issues is left to the developer.

Swing’s continuing maturity removes many justifications for SWT

SWT seems more like an impatient solution to the problems of the first-party Java GUI toolkits than a real attempt to innovate GUI development in Java. Its low-level emphasis may be useful in certain cases, but I’d be hardpressed to see a case where SWT exposes something that Swing is unable to do.

Now, this last point is only more recently true. Swing did lack some expected features, such as system tray access, the capability to open a native browser or email client, and so forth. However, these things have since been remedied by their inclusion in AWT. Swing’s (and Java’s) performance problems have also diminished significantly, further reducing the need for native peers and low-level exposure.

Low-level exposure works against expectations in Java

On a fuzzier note, I find that SWT simply doesn’t feel like Java. This is aggravated by the fact that Java already has a GUI toolkit, so the standards have already been set. SWT’s design goals of exposing the meat of the interface you’re building on seems to work against the design goals of Java itself. SWT finds you having to do such heinous things as explictly disposing resources when you’re done with them.

Of course, explicitly disposing resources theoretically allows you to perform faster and cleaner than the garbage collector would otherwise allow. I am somehow reminded of standard versus automatic transmissions. I am also reminded of Pareto’s principle. If garbage collection is your bottleneck, you’re doing something wrong (or very odd).

Now, the problem I’m getting at here is not that SWT requires explicit resource disposal. Indeed, anything that’s touching the underlying native interface must concern themselves with disposal. The problem is that low-level access as a rule simply isn’t necessary in GUI toolkits.

It feels like someone missed programming GUIs in C/C++ and decided to write something in Java that mimics it as much as possible. They knew such a thing would be laughed out of existence, so they made Eclipse use it and named it something that makes it sound like it’s official.

There is no debate; use Swing

In all seriousness, SWT did solve some shortcomings with Swing in the past. But as Swing continues to improve, SWT’s reasons for existence deteriorate. SWT will not get you magnitudes of performance increase on a noticeable level. Nor will its low-level programming model afford you customization that you can’t do in Swing. I simply don’t believe there are valid, wide-scale arguments anymore for using it over Swing.

---