Swing and SWT: A Tale of Two Java GUI Libraries

Swing and SWT: A Tale of Two Java GUI Libraries
By Mauro Marinilli

In this article, we will talk about Java J2SE graphical user interface (GUI) libraries. We will adopt a programmer's viewpoint in our discussion. We assume the reader is familiar with the basics of the Swing library and wants to explore the SWT technology.

We will discuss two Java GUI libraries:

• Swing—The reference GUI toolkit for J2SE.
• SWT—This library has been developed by IBM as a part of the Eclipse platform.

Eclipse is an open-source, IBM-sponsored, fully extensible IDE, built using Java and SWT. SWT originated as Eclipse's GUI library, but it can be used outside it as a an alternative GUI library to both Sun's AWT and Swing.

In the following section, we will introduce the basics of SWT. We will assume the reader is familiar with Swing. Finally, we compare SWT and Swing.

SWT

SWT (Standard Widget Toolkit) is a graphics library and a widget toolkit integrated with the native window system (especially with Windows but Linux and Solaris are supported as well). Despite the tight integration with the native target platform, SWT is an OS-independent API. SWT can be seen as a thin wrapper over the native code GUI of the host operating system.

At a higher level of abstraction, also a part of the Eclipse platform, lies JFace. This is a GUI library, implemented using SWT, that simplifies common GUI programming tasks. JFace is independent of the given window system, in both its API and implementation, and is designed to work with SWT, without hiding it. For brevity, we will discuss only SWT here.

Introduction

The design strategy of SWT was focused on building a simple, essential library that would produce GUI applications closely coupled to the native environment. SWT delegates to native widgets for common components (such as labels, lists, tables, and so on) as AWT does, while emulating in Java more sophisticated components (for example, toolbars are emulated when running on Motif) similarly to Swing's strategy.

SWT has been designed to be as inexpensive as possible. This means (among the other things) that it is native-oriented. Anyway, it differs from AWT in a number of details. SWT provides different Java implementations for each platform, and each of these implementations calls natively (through the Java Native Interface, JNI) the underlying native implementation. The old AWT is different in that all platform-dependent details are hidden in C (native) code and the Java implementation is the same for all the platforms.

Resources

An important difference from normal Java programming is the way OS-dependent objects are managed in SWT. Swing emulates a large part of such objects (such as widgets, for instance) in Java, leaving the disposal job to the JRE garbage collector. This saves a lot of complexity for the programmer but this lack of control can lead to some unexpected issues, especially with cross-platform development.

SWT designers chose a different approach, obliging the developer to explicitly dispose of OS-dependent objects in the application code. SWT has been designed with efficiency in mind, so handling explicitly OS resources becomes an occasion to promote efficient programming and not just a necessity. Resource disposal is needed to free the OS resources used by the SWT application. Such OS resources need to be explicitly de-allocated by invoking the dispose method.

In practice, disposing of objects is a delicate business and it can lead to unpredictable results whenever another object tries to access an already disposed item.

The Basic Structure of an SWT Program

As already said, an SWT program relies upon the native platform resources (wrapped by the Display class, as we will see later on) both in terms of allocated resources (such as colors, images, and so on) and as regards the event mechanism. As regards event handling, in SWT there is only one thread that is allowed to handle native user interface events.

We now see the basic structure of an SWT program. This will help us understand SWT's basic architecture.

There are two basic classes used in any SWT application, the Display and Shell classes. Instances of the Display class are responsible for managing the connections between SWT and the underlying operating system, enforcing the SWT models (for colors or images, for example). The Shell class instead represents windows managed by the platform-dependent desktop manager.

Typically, an SWT program will first create a local resources manager (an instance of the Display class) and attach all the needed widgets to one or more Shell objects. Listing 1 shows this typical mechanism.

Listing 1: A snippet of code showing the use of the Display and Shell classes.

00:     Display display = new Display();
01:     Shell shell = new Shell(display);
02:     //GUI code here
03:     shell.open();
04:     while (!shell.isDisposed()) {
05:       if (!display.readAndDispatch())
06:         display.sleep();
07:     }
08:     display.dispose();
09:   }
10: }

To fully understand the code in Listing 1, one should understand the readAndDispatch method of the Display class. Such a method reads an event from the operating system's event queue, dispatching it appropriately. It returns true if there is additional work to do, or false if the caller can sleep until another event is placed on the event queue.

The loop at lines 4-9 in Listing 1 is typical of SWT applications. It takes care of forwarding all underlying platform events to the SWT application until the shell is disposed and the program can exit the event loop.

Basic Controls

Some of the basic components (or controls, as they are called in SWT) are the following:

• Button. This component is the well-known button component used in toolbars, forms, and so forth.
• ComboBox. This widget is the well-known combo box component.
• Label. This component represents a (non-selectable) object that displays a string or an image.
• List. This widget represents a basic list component.
• ProgressBar. It shows a progress indicator.
• Sash. It is the Swing equivalent of a JSplitPane. It is a widget that can be dragged to resize two areas in a GUI.
• Scale. This component implements an editable GUI item representing a range of continuous numeric values.
• Slider. This component represents an editable object that stands for a range of discrete, numeric values.
• Table. This component represents a basic table.
• Text. This component represents a basic text area.
• Tree. This component represents a basic tree widget.
• StyledText. This component represents a text area with styled fonts and other advanced attributes.

SWT vs. Swing

We conclude this article comparing these two technologies. Which is better, and when?

Swing provides a larger set of features, it is much more elegant, and gives an higher abstraction level (that turns helpful when developing complex GUIs with custom components). In general, SWT is easier to use at first, but when it comes to building complex GUIs, Swing usually results are easier to use and more flexible. In Table 1, support for the main components is shown for the three main GUI libraries.

Table 1: Comparing visual components
Component	SWT	Swing	AWT
Button	X	X	X
Advanced Button	X	X
Label	X	X	X
List	X	X	X
Progress Bar	X	X
Sash	X	X
Scale	X	X
Slider	X	X
Text Area	X	X	X
Advanced Text Area	X	X
Tree	X	X
Menu	X	X
Tab Folder	X	X
Toolbar	X	X	X
Spinner	X	X
Spinner	X	X
Table	X	X	X
Advanced Table	X	X

At first, SWT may seem simpler to use than Swing because it spares developers from a lot of sophisticated issues (such as the elaborated Swing class hierarchy, pluggable look and feel, the Model-View-Controller approach, and so on). Anyway, one potential problem with SWT is in the need for resource management. Swing (and AWT) follows the Java paradigm of automatic resources disposal, while in SWT de-allocating native resources needs to be accomplished explicitly by the programmer. Explicitly de-allocating the resources could be a step back in development time (and costs) at least for the average Java developer. This is a mixed blessing. It means more control (and more complexity) for the SWT developer instead of more automation (and slowness) when using Swing.

Although SWT supports non-natively rendered widgets (similarly to Swing), the default widget implementations are based on native peers (similarly to the old AWT). In addition, most of the Eclipse peers do not allow for inheritance. (Obviously, if you're writing Eclipse plugins, you have no choice but to use SWT.)

Recapping, whenever one needs a tight integration with the native platform, SWT can be a plus. Similarly, if one wants to take advantage of the Java language but needs to deploy only on Windows (or some of the few other supported platforms), SWT (and the Eclipse platform) is a better choice than Swing. But, be careful about the hidden costs associated with learning to use the Eclipse IDE and the SWT library. Also, the explicit de-allocation mechanism adopted in SWT could be useful in some situations and uselessly complex in others. If you don't need cross-platform development and your target OS is supported (Windows, for example), you may consider SWT, especially if your customers have old, limited machines where Swing use can be prohibitive. For all other scenarios, Swing provides the conservative choice.

Conclusions and References

In this article, we introduced SWT and compared it with Swing. My intent was to give a first idea of this library and its main characteristics. We concluded contrasting briefly SWT against Swing.

In the following are listed some (among the many) resources available for the interested reader.

• http://www.eclipse.org/—The home page of the Eclipse project.
• http://gcc.gnu.org/java/—The home page of the GCJ project.
• http://www.java.sun.com/products/plugin/—The official Sun Web site about Swing technology.
• http://www-106.ibm.com/developerworks/library/j-nativegui/—The site for Vogen, Kirk's article "Create native, cross-platform GUI applications."

About the Author

Mauro Marinilli is currently finishing his second book, on professional Java graphical user interfaces. He teaches CS courses at the University of Rome 3 in Italy while being active as a consultant and as an academic researcher in case-based reasoning, Human Computer Interaction and its applications to e-learning. You can email him at contact@marinilli.com.