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.