SWT - The Challenger

SWT ”The Challenger

Thus enters SWT, the Software Widget Toolkit. SWT is, in some ways, a throwback to the old days of AWT, because SWT is designed to use the native operating system graphical APIs for drawing most of its basic widgets. Although SWT adds support for higher-level concepts such as layout managers, the lower-level SWT widgets rely upon the native OS APIs for their functions.

Unlike the original Swing, which was designed in something of a vacuum without a whole lot of practical application, SWT has been designed in conjunction with its primary application, the Eclipse workbench. And while there is some debate over whether the look and feel of SWT has enough advantage in speed and "native feel" to justify it, there's no doubt that the interface is quite successful in supporting a major development effort.

There are a few differences in basic programming, some subtle, some not so subtle, but the general concepts are quite similar. You create containers and put widgets in them, optionally using layouts to determine the position of those widgets. You can attach listeners to the widgets, written to respond to user actions. Some of the interfaces definitely can be seen to be second generation, in that they build upon and improve their counterparts from the Swing API. Others are simply different, and some are actually more difficult. One of the biggest gripes is that many of the resources you allocate during SWT programming ”things such as windows and colors ”must be managed by the programmer. Failure to return these resources to the system can cause memory leaks. This is diametrically opposed to the Java concept of garbage collection, and it is a common problem when directly accessing the native OS.

Moreover, there is a very fundamental difference in deployment. For each operating system, you must include a native library, such as a DLL in Windows or a shared library in Linux. This native library is constantly evolving, so you must include the correct one for your version of SWT with your application. Any operating system that does not have a native library cannot run SWT applications. And while the SWT development team seems to be making every effort to support a wide variety of operating systems, this is just one more piece of OS-specific software you need to worry about.

So, the tradeoff is simple: a more native, more responsive look and feel, or a more portable but perhaps less powerful API. You'll need to make your decision based on your business requirements, but hopefully I've given you some information to help you make that decision.

The Swing Source

I thought it was important that any book that deals with Eclipse should also deal with SWT, since SWT is the underlying user interface for Eclipse. Makes sense, eh? Not only that, there was no real tutorial on using Swing and Eclipse together, and as I found, it's not exactly intuitive.

So, all the primary examples in the book use SWT as the interface. This is not meant to be an opinion as to whether SWT is better than Swing or vice versa; it is simply the decision made when selecting the content of the book.

However, I know that some of you may be familiar with Swing and may prefer it. Alternately, some of you may have no idea whatsoever what Swing is and may want to see some examples of Swing code. To that end, I have included Swing versions of the various graphical application in this book, as follows :








/Source/Step 9/HelloSWT.java




/Source/Step 9 (Swing)/HelloSwing.java




/Source/Step 9/Prompt.java




/Source/Step 9 (Swing)/PromptSwing.java




/Source/Step 10/lnquire.java




/Source/Step 10 (Swing)/InquireSwing.java

There were two thick-client applications in Step 9 and one in Step 10. The examples in the book are all SWT. For each SWT example there is a corresponding Swing example. All code for both UI types is on the included CD-ROM.