What is the difference between AWT and SWT?

Scott Stanchfield

SWT (Standard Widget Toolkit) is a completely independent Graphical User Interface (GUI) toolkit from IBM. They created it for their new Eclipse Integrated Development Environment (IDE).

IBM began work on SWT a few years ago, because Swing was still immature and didn't perform well. They decided to create a new toolkit to provide better performance using native widgets.

The basic concepts behind SWT and AWT are fairly similar, but the implementations are quite different:

  • Users write programs that use the AWT or SWT libraries for GUI widgets.
  • AWT and SWT delegate widget control to the native components on the user's machine.

The AWT Way

The big difference is how the two toolkits use the native components. In AWT, native "peer" code, written in a language like C or C++, is used to control the real widgets on the system. If you're running on Windows, this peer code uses MFC or Win32 calls to display widgets. On other platforms, the native GUI calls for their operating system/window manager are used.

Each Java Runtime Environment (JRE) distribution provides a unique set of peers for the target platform. The Java Classes stay the same; the native code changes.

AWT implementations suffer three key problems because of this structure:

  • Not all platforms support the same widget set, so a "least common denominator" effect occurs. AWT only provides a very basic set of components, ones that all modern platforms provide.
  • If you want to provide a component that exists on some platforms but not others, you must code it entirely in Java (or use JNI, which would limit that code to one platform). This is the implementation strategy of Swing -- Swing components are written in Java, drawing the new components like Trees and Tables using AWT graphics calls.
  • A good chunk of the GUI logic is buried in C or C++ code (that isn't delivered with the normal Java SDK distribution). This can make it difficult to find errors that occur because you can't see this code executing in a debugger.

The SWT Way

IBM took a different approach. Rather than write the peers in native code, they wrote a thin Java Native Interface (JNI) layer for each platform that exposes the GUI API of that platform. Java code, similar to the AWT native-code peers, uses calls to the native API for that platform to control the widgets.

With SWT, some of the library Java class implementations vary between platforms, rather than distributing native peer code.

This solves the three above problems with AWT:

  • (For the first two problems) If some platforms support a widget that others don't, the widget can be made native on those platforms and emulated on the others. In both cases, only Java code has to be written to take advantage of it. For example, Windows provides Trees and Tables, so SWT's Java code calls the MFC/Win32 libraries to display the trees and tables. If another platform didn't provide trees or tables, the Java code for that platform could draw them.
    • A key advantage here is that a tree or table really is the platform's tree or table on platforms that support it natively. Swing has to emulate the tree or table, and it's very hard to get it exactly right. Not to mention, upgrade to Windows XP. and the trees and tables will actually look different if you use SWT. Using Swing, they'll still look like Windows 9x/2000.
  • All of the logic added for SWT is written in Java; there's no significant C/C++ code. Debugging the toolkit becomes easier. (And it's easier to tell exactly what the toolkit is doing "behind the scenes").

Applications vs. IDE

SWT was designed for use in the Eclipse IDE. It wasn't initially intended to be used for standalone applications. However, later this year (2001), IBM plans to open-source Eclipse and SWT, and you can use it for applications if you would like. Building GUIs using SWT feels a little different than AWT, but there are definitely some similarities. Watch for SWT tutorials at the Eclipse web site (http://www.Eclipse.org)

If you write plugins for the Eclipse IDE, you should use SWT. Yes, it's another API to learn, but you must consider it from the end-user's point of view. SWT is the GUI toolkit used for Eclipse, and Eclipse is an Integrated Development Environment. Using SWT keeps everything looking and feeling the same.

For More Information

A more detailed discussion of SWT architecture appears at http://www.eclipsecorner.org/articles/Article-SWT-Design-1/SWT-Design-1.html.

For other details on Eclipse and SWT, please visit http://www.eclipse.org.