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
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-Eclipsebased 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
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
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.
Bernie Spang, director of WebSphere Studio Marketing, is a computer engineer
who led the public launch of the Eclipse project in 2001.