In his editorial "Swing Is Swinging Java out of the Desktop" (JDJ, Vol. 7, issue 10) Alan Williamson lamented the current state of Swing and AWT for building competitive desktop applications. One alternative he mentioned is a technology called SWT (Standard Widget Toolkit) that was developed as part of the Eclipse Project (www.eclipse.org). If you're wondering why the Eclipse community, led by IBM, developed SWT instead of using J2SE's AWT or Swing classes, here's the reason.

Eclipse is an open, universal platform for building and integrating development tools. The users of development tools are, typically, developers and they are a demanding lot. So Eclipse had to be designed to deliver a high-performance user experience and integrate well with native operating systems. In the early development phase of the project, the Eclipse developers found that AWT was too limited and Swing did not provide the native integration and performance they needed. Not to say that either is inherently good or bad, just that they didn't meet the requirements of this particular Java application. And that's an important point ­ the Eclipse platform is a Java application that runs on the J2SE platform.

As Alan pointed out in October, AWT does not provide a satisfying solution for most desktop applications. But Sun provides additional functions in the Swing classes to give Java developers the power of maximum user interface customization and cross-operating system consistency. The power of the Swing classes comes at a price, however, paid in abstraction from the operating system platform and its effect on application performance. In the case of Eclipse, it was not a priority to have an identical user interface across different platforms, but rather to maximize performance and integration and leverage each platform's capabilities. Thus SWT was born.

Swing and SWT both provide a common programming API across multiple operating systems, but that's where the similarity ends. Swing widgets are rendered by Java code, using graphics calls to "paint themselves," while SWT widgets use the operating system widgets directly via J2SE's JNI API. Since SWT is designed to embrace native window systems rather than emulate them, SWT applications have the exact look and feel of the host operating system. This means, for example, that SWT applications pick up the new Windows XP look without any code changes or delay while new emulation code is developed. This design approach also allows an application to leverage platform features such as drag-and-drop and event-merging optimizations. The result is that SWT applications truly look and perform like native applications.

SWT was developed because the Eclipse community needed a high-performance widget toolkit that integrated fully with Windows and other native toolkits such as GTK and Motif. But with the rapid and widespread adoption of Eclipse technology, many developers have found that SWT also answers an important need they have for high-performance native user interfaces in their non-Eclipse­based applications.

SWT is available for anyone to use under a true open-source license, and is developed and maintained by an open-source community. However, many Java developers feel it is time for SWT to be submitted to the JCP to bring it into the Java "fold," so to speak, as an additional user interface option. IBM would likely support a JSR that incorporates SWT as a complement to the AWT and Swing options ­ along the lines of how Java specifications incorporate support for other open-industry technologies such as XML and SOAP.

At the end of his editorial Alan says, "If you need your faith in Java reenergized, look to the community and what they are doing." We couldn't agree more.

Author Bios
Dave Thomson is VP of development at IBM's OTI Labs and led the team that developed the Eclipse technology. Dave is a member of the Eclipse.org board and an IBM Distinguished Engineer. dave_thomson@ca.ibm.com