The first question one should ask, perhaps, is why create an alternative GUI? Good question. The answer, according to the SWT FAQ,^[3] primarily has to do with execution speed and look-and-feel similarity to native GUI applications on each platform.

If we may editorialize, we find neither reason particularly compelling, although the execution speed argument made some sense when the Eclipse project started. Swing is unlikely to win any performance awards, even though each version brings some improvements in speed.^[4] Still, these reasons do not seem particularly compelling for such a large duplication of effort and functionality.

Whatever the reason, SWT exists. SWT works by providing a thin abstraction layer over native GUI features. It is a small GUI library. It is implemented using the Java Native Interface, so it requires that a native binary library be implemented for your platform. Fortunately, such implementations exist for all platforms Eclipse runs on. So if you can run Eclipse, you can write and run SWT applications.

The next logical question is, “If you think SWT is unnecessary with Swing already there, why cover it in your book?” Also a sensible question. The answer is that there is very little published literature on this library (a notable exception being Chapter 10 of The Java Developer’s Guide to Eclipse by Shaver et al., from Addison-Wesley). Also, SWT provides the only fully functional GUI library that will work with the GNU Compiler for Java. As such, it is a major required component if you wish to write native compiled GUI applications on Linux systems.

Of course, there is another reason. Anyone heavily into Linux is well aware of the political and philosophical debate about Free Software and Open Source. If the core values of Free Software are critical for you, you should be aware that the IBM Common Public License^[5] under which Eclipse (and thus SWT) are published is a Free Software license. You get the source code, you may use it in your own products, and it imposes obligations similar to the GNU GPL,^[6] but goes even further by requiring you to grant royalty-free licenses for any patents you hold in derivative works.

So you might choose SWT (or not) for political or philosophical reasons. Both authors still suggest Swing first because it is the official Java GUI library. When an employer wants to know if you can write a Java GUI application, he or she almost certainly means a Swing application. Philosophy is great, but it may not put the food on your table. You need to know that Swing is not Free Software (and neither is either of the major Java SDKs), and SWT is Free Software, but it is up to you to decide what best serves your interests.^[7]

How about portability? Well, it depends on what “portability” means to you. If portability means “looks and runs the same on all platforms,” then Swing offers better portability. If portability means “runs on all platforms for which there is a Java runtime,” then Swing offers better portability. If portability means “looks like a native application on all supported platforms,” then SWT is your choice. Make your selection accordingly.

The rest of this chapter will be devoted to describing the basic classes of SWT by converting one of the application classes from the previous chapter from Swing to SWT. We will not attempt to explain the operating principles of GUIs. For an introduction to GUI programming, see the previous chapter on Swing. It introduces the concepts and programming principles for GUI programming in Java. SWT is functionally similar, although quite spartan, providing only basic windows, controls, and events.

Eclipse also contains a family of higher level user interface classes, known collectively as JFace, that provide UI features such as dialogs, wizards, font handlers, and images. We will not cover JFace in this book.

SWT breaks some of the Java contract. For example, you cannot rely on garbage collection to clean up SWT objects. Any SWT object you create with new must be explicitly destroyed with a call to the dispose() method. Why? Since SWT is implemented with native methods, the low-level implementation allocates native OS data structures and objects that must be explicitly freed. Since the Java garbage collector cannot be relied upon to collect objects at a certain time (or ever, for that matter), these allocations can result in memory leaks and address space conflicts. As we shall see, however, SWT is well designed to minimize the amount of this that you need to worry about.

SWT is also close to the metal in the sense that it does not abstract the underlying message-based event system that drives both X Window and Microsoft Windows. If you have ever written an X Window or Microsoft Windows application in straight C (without a GUI framework library or class library), you have written a main() function that contains an event loop. SWT actually puts simple method calls around this core message queue event loop. We’ll cover the details of this in the next section where we introduce the Display and Shell classes.

SWT consists mainly of classes that represent controls—such as buttons, text areas, scrollbars, and so on—and layout managers which are much like layout managers in Swing. But there are two other classes: Display, which models the interface between your Java application and the underlying windowing system, and Shell, which effectively represents a single window.

The application in Example 17.1 is a parallel to the simple Swing program in the last chapter (Example 16.1).

This simple program, like its parallel in the Swing chapter, is deceptive. Sure, this is a lot of code to say “Hello, world” but it is because what we are setting up here is an event-driven program that must respond to any valid user input.

Setting Up to Run an SWT Application

One advantage of Swing that we haven’t pointed out up to now is that it is part of every Java runtime (well, not gcj; more on that later), so you have all the classes on your classpath without any special setup. Not so with SWT. The exact procedure for setting up to run an SWT application depends on what development environment you are using.

There is an excellent set of directions for running an SWT application under Eclipse in the SWT FAQ.^[8] No matter what your environment is, there is a basic series of steps:

1. Download the Eclipse SDK.

2. Install it.

3. Extract the SWT JAR files.

4. Extract the SWT JNI files.

5. Configure your development environment.

Example 17.1. A simple SWT application

import org.eclipse.swt.*;
import org.eclipse.swt.layout.*;
import org.eclipse.swt.widgets.*;

/**
 * @author mschwarz
 *
 * Sample SWT "Hello, world" application
 */
public class SWTHelloWorld {

  public static void main(String[] args) {
    Display disp = new Display();
    Shell window = new Shell(disp);
    window.setLayout(new RowLayout());
    Label label = new Label(window, SWT.NONE);
    label.setText("Hello, world.");
    window.setSize(320, 160);
    window.open();

    while (!window.isDisposed()) {
      if (!disp.readAndDispatch()) {
        disp.sleep();
      }
    }

    disp.dispose();
  }
}

Let’s go over these in a bit more detail.

SWT was developed as a GUI library for the Eclipse project. It is distributed as part of Eclipse. There is no official standalone SWT package. The right way to obtain SWT is to download and (at least temporarily) install the Eclipse SDK. See Section 10.4 for details.

If you have followed our sage advice and downloaded the GTK version of the Eclipse SDK, then you need to copy out the SWT JAR files. There are two files in the GTK version, and just one in the Motif version. The GTK version’s files are swt.jar and swt-pi.jar. They are both in the eclipse/plugins/org.eclipse.swt.gtk_2.1.2/ws/gtk directory. You will need to have both of these JAR files on the classpath of any SWT application you are compiling or running.

Remember that SWT is a JNI library. You must also have the native Linux shared libraries. These need to be made available to the Java native loader. The files you need are located in the eclipse/plugins/org.eclipse.swt.gtk_2.1.2/os/linux/x86 directory. The .so files there must be available to any running SWT application. There are a couple of ways to do this. First, as described in Section 5.7, you can set the LD_LIBRARY_PATH environment variable. You also can use the -D parameter for the runtime VM to set the java.library.path property.

If you want to, you can copy these files out of the eclipse directory to some other location and then erase the eclipse directory with the lovable old standby, rm -rf eclipse.

Oh, by the way, once you have compiled the sample code above and set your classpath and Java library path correctly, running the application produces the window shown in Figure 17.1.

Figure 17.1. Running the SWT version of “Hello, world”

We are going to tackle converting BudgetPro.java from Swing to SWT. In real life, this is an exercise you are unlikely to have to carry out. You will more likely write your GUI applications from scratch. But going through the conversion provides a useful roadmap for talking about the architecture of SWT; it teaches you SWT in terms of a class library with which you are already familiar.

First off, we change the packages imported at the start of the file. Remove all of the awt and swing packages. If you are using an IDE, this should flag every single line of code that touches the GUI as an error. This can be a big help when you are doing a mass conversion like this. When you have killed all the compile errors, you know you are well on your way to completing the conversion.

Replace the import statements with the imports you are likely to need for your SWT application. These are:

import org.eclipse.swt.*;
// The static SWT class, which contains a number of constants.

import org.eclipse.swt.widgets.*;
// The widgets library.  Almost all your display elements are here.

import org.eclipse.swt.events.*;  // Event handlers

import org.eclipse.swt.layout.*;  // Layout managers

We will go into these families of classes in more detail as we convert the members and methods of BudgetPro.java.

The next step is to convert the GUI members of the class from the Swing classes to their SWT counterparts. Of course, SWT requires the Display class, which has no analog in SWT, so we add a Display type member named disp just ahead of the frame member.

Next, we change the type of frame from JFrame to Shell. We could rename the member,^[10] but why add to our typing burden? The name is still clear and meaningful, even if it doesn’t match the SWT name.^[11] There’s more to it than just changing the type, however. The constructor call for the JFrame doesn’t match any constructor for Shell. In fact, the Shell constructor requires a Display object argument, and all subsequent constructors for widgets and controls require a Composite as an argument.

This is a key difference between Swing and SWT. Swing allows you to build GUI components in arbitrary order at arbitrary times and then join them up to the GUI with an add() method call. SWT instead requires that you link your components up to the GUI element they belong to when they are constructed. There are good reasons for this difference. Remember that SWT allocates native objects and memory that Java’s garbage collector cannot recover. Because of this, SWT makes the promise that if you call the dispose() method on any SWT object, it will dispose of it and everything it contains. That allows you to clean up all resources from an SWT program by calling dispose() on the top level Display object. If SWT allowed you to build GUI structures independently and then graft them onto the hierarchy, it could not keep this promise. For this reason (amongst others) SWT objects are always built in a fairly rigid top-down manner.^[12]

The most direct consequence of this is that we have to get rid of the constructors on these declarations. We’ll start construction in the main(). So, away with the constructors for the GUI elements. We now need to change the JButtons to Buttons and the JLabels to Labels. Again, if you are using a dynamic IDE, you should see your error count skyrocket with these changes (well, maybe not really skyrocket, since the import changes have already produced a lot of errors right off the bat).

Finally, we remove the AbstractTableModel member. SWT has a simpler (and more limited) table functionality that we will discuss later.

The main (pun unintended) changes that need to be made here include allocating the SWT Display, changing from instantiating a JFrame to a Shell, doing away with the Swing “look and feel” stuff (an SWT application always looks like a platform-native application, that’s SWT’s main selling point), and reworking the construction of the GUI. We’ll explain that a little bit later.

For now, we take care of the simple changes. Remember that main() is a static method, so we do not have any nonstatic class members available right now. The original BudgetPro constructor took a JFrame argument, now it will have to get a Display and a Shell. So we have to allocate a local Display and a local Shell. We also need to add the Display argument to the BudgetPro constructor.

After this is done, we modify the call to the constructor to pass the local Display and Shell to our class instance.

Next, we have to set a layout manager. The original application used the Swing BorderLayout layout manager. SWT doesn’t have such a critter. Fortunately, the original used only the north, center, and south positions of the BorderLayout. SWT has a simple layout manager called a FillLayout that puts its contained controls in a single row or column, equally sized. Putting the three controls in a column will end up looking much like using the north, center, and south of a BorderLayout. So we change the call to the frame.setLayout() to pass in a new FillLayout and add the SWT.VERTICAL attribute.

The next block of code in main() sets the Swing look and feel. SWT has nothing like this. All SWT applications look like native applications (we seem to be saying that a lot), so all of this code may be removed.

The next block of code calls methods on the application object (app) that, in the original, construct the three “chunks” of UI and add them to the frame using the BorderLayout attributes. Since, as we explained earlier, all SWT controls must be explicitly joined to a parent control when they are constructed, the separate create-then-add semantics used in the original will not apply. In the next section, we will walk through converting one of these three create methods. For now, it is enough to know that they will be changed to be methods that return void (no return value) and the calls to add() may be deleted.

That completes the conversion of main().

Lest you believe that this means the application is ready to run, just try compiling what you have. Got a few errors yet, don’t we?

Let’s walk through converting the createStatus() method and its related methods. We’ll then briefly discuss converting the createList() and createButtons() concentrating on the details of the unique UI widgets used in each.

private SelectionListener upAction = new SelectionAdapter()
{
  public void widgetSelected(SelectionEvent e)
  {
    // this is the action for UP arrow icon;
    Account next;
    next = current.getParent();
    if (next != null) {
      current = next;
      setStatus();
    }
  }
} ;

To keep this book to a reasonable size, we are always trying to avoid covering the same ground more than once. We won’t walk you through the details of converting the createList() and createButtons() methods as we did with the createStatus() method, but we will talk about the details of converting to SWT of some of the classes used in those methods.

Completing the conversion of the BudgetPro class does not complete the conversion of the entire application. The AcctDialog class must also be converted. Use the same techniques we described here to convert that class as well. (Or, again, just download the complete SWT application.)

Our overall impression is that SWT is more easily comprehended in its entirety than Swing. It may be easier to learn SWT first, since Swing’s core model is more complex but more powerful. But SWT and Swing weren’t developed in that order and Swing is still much more widely used.^[16]

For many GUI applications, our feeling is that it may be faster to write in the SWT idiom. The problem lies in that SWT’s model has limitations that Swing’s does not. Notably, SWT GUI elements are in a single rigid tree structure. It is not possible to have a factory class that constructs a GUI element such as a dialog box which is passed up to the caller to be grafted into place on a GUI. Instead, the parent element must be passed in, so all GUI elements belong to the single tree from the moment they are created. Also, by introducing objects that cannot be garbage-collected, SWT brings into your application the possibility of a class of bugs that Java otherwise eliminates.

Moreover, while converting a Swing application helped give this chapter shape, we would, in general, prefer that an application be designed with its GUI toolkit in mind. You would likely make slightly different design decisions depending on which style of the GUI you choose.