JavaFAQ Home » Swing, AWT
Question: What is SWT? And what is useful for?
Answer: SWT is a widget toolkit for Java designed to provide efficient,
portable access to the user-interface facilities of the operating systems on
which it is implemented.
The most succinct description of the Standard
Widget Toolkit component is this:
The SWT component is designed to provide efficient, portable access to
the user-interface facilities of the operating systems on which it is
The SWT component implementors take each of the terms in this statement to
have a very specific meaning:
implies that SWT must be as thin a layer on top of the operating system
facilities as possible. So, for example, SWT avoids the use of
a separate peer layer as is found in the Sun AWT
class library, thereby gaining increased speed and space efficiency at the
cost of some amount of implementation flexibility. SWT also attempts to
avoid "sugar coating" the limitations of the underlying
operating system, since doing this always implies significant overhead in
addition to introducing the potential for subtle failures and
incompatabilities; this is the "sometimes you have to let the o/s
win" rule. An example of the kind of problem that SWT would not
attempt to hide is the existence of limitations on cross-threaded access
The only exceptions to the rule are cases where a particular operating
system is missing features that are required for it to be a candidate
Eclipse platform. If some small set of specific, clearly defined
"workarounds" can be made to enable Eclipse to run on this
target, then they will be implemented. For example, the lack of a ToolBar
type widget on Motif was addressed by providing an "emulated"
version on that window system, since ToolBars are fundamental to the
Eclipse look and feel.
implies both that it must be possible to create applications (Eclipse,
in particular) which will run on all of the supported operating systems,
and that SWT itself must be simple to port to new operating systems.
"access to the user-interface facilities of
the operating system"
The former case is supported by providing a common programming interface.
By coding to this API, applications can be created that run everywhere
where SWT will run. It is important to note that, because SWT uses the
native (i.e. operating system provided) widgets, the look and feel of
applications built with SWT will vary on each operating system so that
they match the expectations of users of that operating system.
The later case, the porting of SWT itself, is supported by ensuring that
all but the lowest-level, direct interface to the operating system is
written in Java. In SWT there truly is "nothing interesting in the C
natives", which makes the initial porting (and subsequent debugging)
of SWT considerably easier since it can largely be done using the
facilities of Eclipse, including the built in remote debugging. In
addition, the coding style of SWT is such that it is easy for programmers
that are familiar with a particular operating system to understand and
implement the code.
A side-effect of the SWT implementation strategy is that it is relatively
simple to create operating system specific extensions to SWT to support
particularly important features. An example of this would be ActiveX on
Windows, which Eclipse uses (protected by appropriate platform checks) to
support embedded ActiveX controls and do*****ents. It was felt that to be
competitive on that platform, support for ActiveX was a requirement, even
though it was not available elsewhere. Because SWT is "close" to
the platform, this was not a difficult task.
Although this has already been stated, it is worth reiterating that the
widgets that the SWT component provides are those that are provided by the
operating systems on which SWT runs. The intent is to allow access to
these native widgets (and the other operating system user-interface
facilities), not to "roll our own" new widget system. As such,
although the SWT component implementors try very hard to make it possible
for consumers of SWT to be able to ignore which operating system they are
running on, developers need to understand that applications can
potentially behave differently to match the operating system behavior. For
example, programatically giving focus to a "radio" button on
Windows will cause it to be selected. Period. Since it would be
exceedingly difficult (and is counter to the Windows user-interface look
and feel) to prevent this behavior, the Windows version of SWT generates
events as if the user had "clicked" the radio button when it is
given focus. This means that well-written applications can ignore the
differences, but also means that smart developers will test SWT
applications on every platform which they are to be delivered on.
If that was all there was to this story, then everything would be clear cut.
However, in addition to the work described above, the SWT component is
responsible for one additional aspect of Eclipse: the implementation of the
custom widgets which provide the specific look and feel (i.e. the
"branding") of Eclipse. This is a complex task, since it requires
a delicate balance between the particular vision of the user-interface
designers, and the desire for the widgets to have appearance and behavior
that is consistant with the user-interface guidelines of the operating
It is important to note that, if Eclipse were to be built entirely from
custom widgets and used no native widgets, then the SWT component
implementors would consider their work to be a failure. The intent is to
provide a small set of carefully considered custom widgets to give Eclipse
its distinguishing features in a way that is still strongly oriented towards
the look and feel of the platform. For example, when the user modifies the
appearance of their desktop using platform provided mechanisms (setting
default window background colors, border widths, "skinning", etc.)
the custom widgets should reflect these changes whenever (a) the changes can
be detected and (b) they do not specifically contradict the brand
Currently, all custom widgets are coded in terms of existing SWT widget and
graphics APIs. They are portable and use underlying SWT mechanisms to ensure
that they have correct appearance. Although this already works quite well,
one of the research areas for the SWT component is to further improve the
ability to match the platform appearance, for example in the presence of
"programatic skinning" as provided by window systems such as GTK+.
Another exciting aspect of SWT is that it is also being used as part of
the underlying implementation for several embedded systems efforts because
of its small size and focus on efficiency. The most notable of these,
currently at least, is in the AWT implementation provided as part of the
VisualAge/MicroEdition class libraries, where SWT effectively becomes the
peer layer for AWT. Further effort is ongoing to improve SWT's utility in
And finally, one last aside: The above discussion blurs and sometimes
ignores the distinction between operating systems and window systems. We do
understand the difference, but wanted to avoid making things even more
verbose than they already were.
All this info, a lot of code snippets and more info on SWT can be found here..
Printer Friendly Page
Send to a Friend
Search here again if you need more info!