4.1. SWT History and Goals

The roots of SWT go back more than a dozen years to work that Object Technology International, or OTI (then an independent pioneering OO software company and now a part of IBM), did when creating multiplatform, portable, native widget interfaces for Smalltalk (originally for OTI Smalltalk, which became IBM Smalltalk in 1993). IBM Smalltalk's Common Widget (CW) layer provided fast, native access to multiple platform widget sets while still providing a common API without suffering the "lowest common denominator" (LCD) problem typical of other portable graphical user interface (GUI) toolkits.

For many years, IBM had been using Smalltalk as its "secret weapon" when building development tools (even IBM's first Java IDE, VisualAge for Java, was written in Smalltalk); however, Smalltalk had deployment and configuration problems that ultimately doomed its long-term use at IBM.

Java's promise of universal portability and ubiquitous virtual machines (VMs) on every desktop was very appealing to the folks at IBM responsible for creating the next generation of development tools. In Java, OTI also saw another language to which it could apply its many talents.

Sun's initial attempt at providing a portable widget API, the Abstract Windowing Toolkit (AWT), suffered from both an overly complex interface to the native widgets and the LCD problem. It provided access to a minimal set of widgets, such as buttons, labels, and lists, common across most platforms but did not provide access to richer widgets such as tables, trees, and styled text. That, coupled with an anemic API, destined it to failure in the marketplace.

To solve the problems of AWT and to provide Java with a more powerful, extensible GUI library, Sun decided to abandon native widget interfaces and developed its own portable, emulated widget library officially known as the Java Foundation Classes (JFC)more commonly known as Swing. Interestingly enough, this paralleled the developments in the Smalltalk world many years earlier when ParcPlace brought the world's first, truly portable, multiplatform GUI environment to market in a product called VisualWorks (many of the ex-ParcPlace engineers responsible for the portable, emulated GUI library in VisualWorks ended up working at Sun).

While Swing solved the LCD problem by providing a rich set of widgets, the emulation of the platform widgets left much to be desired. Swing applications ended up feeling like Swing applications, not the platform native applications they were meant to replace. Swing applications also suffered from performance problems not present in their native counterparts.

While AWT was able to run on the Java 2 Platform, Micro Edition (J2ME) devices, Swing could not because of the large runtime Java virtual machine (JVM) footprint and its reliance on fast native graphics to draw every emulated control. OTI was given the task within IBM of tooling for J2ME, and decided that AWT was not a good enough toolkit. It provided only a basic set of controls, and because its architecture necessitated using the JavaBeans component model, which allows null construction, it had a two-tiered object layer that used valuable JVM memorysomething important to manage wisely on small devices.

Uncomfortable with the philosophy behind Swing and emulated widget libraries in general, and armed with extensive knowledge about how to correctly build native, portable, multiplatform widget libraries, OTI set out to correct the faults of both AWT and Swing and to produce the GUI library that AWT should have been. The result was the Standard Widget Toolkit. OTI used the same developers who created CW for Smalltalk to create SWT for Java.

SWT was designed to have as small a JVM footprint as possible. The CW had two layers, including an OS layer; however, for SWT, it was felt that a single layer was better, where each platform's implementation would be a set of completely optimized Java classes that went straight to native as soon as possible. The public API was the same, but it was not directed through an intermediate layer.

OTI used SWT to build VisualAge Micro Edition (VAME), their first IDE written in Java. When IBM decided to build a common tools platform (Eclipse) on which they could re-base their successful existing products, they initially built it using Swing. It was an early release of Swing in Java 1.2, and IBM was greatly disappointed with its performance and look-and-feel. There were memory leaks in Swing in addition to other defects, which led to its eventual abandonment.

One of the reasons SWT was chosen was because IBM's tooling effort was intended to compete head-to-head with Microsoft, and it was felt that SWT would give a rich enough UI experience. It was a huge risk at the time; SWT had not been ported to many platforms, and also by adopting SWT there was the potential that customers might say: "If Swing wasn't good enough for your toolkit, why should we use it?" Additionally, anyone writing plug-ins would have to use SWT instead of Swingthe fear was that there would be a natural antagonism toward learning this new application programming interface (API). There was also the possibility that SWT versus Swing would fragment the Java community. All these fears came true.

However, SWT has found a lot of favor with people who are now using it to program applications with the Eclipse Rich Client Platform (RCP) because they like its higher speed and platform integration. Arguably, Sun did take its eye off the ball with the 1.2 and 1.3 Swing releases. With JDK 1.4, Sun's Swing performance and its look-and-feel classes are much improved, so that developers who use it now have a greatly improved toolkit.

Without SWT threatening to become the new standard, it's difficult to know whether Sun would have done this work to try and catch up, so having the two toolkits is actually good for users of both. In the past, interoperability between the two toolkits was poor, although this has improved dramatically in Eclipse 3.0.

SWT is the foundation on which the entire Eclipse UI is based. It is fast, native, and multiplatform, but it does not suffer the LCD problem present in AWT or the look-and-feel problem present in Swing. SWT does this by taking a best-of-both-worlds approach: It uses native widgets whenever possible on a platform and supplements them with emulated widgets on platforms where they don't exist; a good example of this is the tree widget that exists in native form under Windows, but is emulated under Linux. The result is a rich, portable API for building GUI applications that adhere very closely the look-and-feel of each platform they support.