Standard Widget Toolkit
| Company type | Software toolkit |
|---|---|
| Industry | Software development |
| Predecessor | Abstract Window Toolkit (AWT), Swing |
| Founder | Stephen Northover |
Area served | Cross-platform (Windows, Linux, macOS, Unix-like systems) |
Key people | Stephen Northover, Erich Gamma |
| Products | Graphical widget toolkit for Java |
| Owner | Eclipse Foundation (current) |
| Parent | Eclipse Foundation |
| Website | www |
The Standard Widget Toolkit (SWT) is a graphical widget toolkit designed for the Java platform. Initially created by Stephen Northover at IBM, it is currently overseen by the Eclipse Foundation alongside the Eclipse IDE. SWT offers an alternative to the Abstract Window Toolkit (AWT) and Swing GUI toolkits, which are provided by Sun Microsystems as part of the Java Platform, Standard Edition (J2SE).
SWT achieves its graphical interface rendering by interfacing with native operating system GUI libraries via the Java Native Interface (JNI), much like applications that utilize OS-specific application programming interfaces (APIs). Although SWT applications maintain portability, the toolkit’s implementation varies across platforms, despite being partially developed in Java.
Released as free and open-source software under the Eclipse Public License, SWT holds approval from the Open Source Initiative.
History
The earliest Java GUI toolkit was the Abstract Window Toolkit (AWT), introduced with JDK 1.0 as a straightforward Java wrapper around native OS widgets such as buttons and menus.
With J2SE 1.2, Swing was introduced, offering a more extensive collection of GUI components entirely implemented in Java. Unlike AWT, Swing renders its own widgets using Java 2D, without depending on native system widgets.
SWT’s development traces back to efforts by Object Technology International (OTI) during the 1990s on cross-platform native widget interfaces for Smalltalk, which evolved into IBM Smalltalk in 1993. The Common Widget layer in IBM Smalltalk provided efficient native access to multiple platform widget sets through a unified API, circumventing the "lowest common denominator" limitation often seen in other portable GUI toolkits.
IBM was also working on VisualAge, an IDE developed in Smalltalk, which was later open-sourced and led to the creation of Eclipse, intended to rival IDEs such as Microsoft Visual Studio. Since Eclipse is based on Java, IBM developers designed SWT as a replacement for Swing to achieve a "native look and feel" alongside enhanced "performance."
Design
SWT acts as a wrapper around native code objects like those from GTK and Motif. Its widgets are frequently termed "heavyweight" due to their direct reliance on native GUI elements. When native libraries do not offer certain functionalities, SWT supplements them by implementing GUI features in Java, similar to Swing’s approach. This design allows SWT to combine the native appearance and low-level efficiency of AWT with Swing’s higher-level ease of use.
According to the Eclipse Foundation, SWT’s goal is to deliver a unified API for native widgets across various platforms, emphasizing high performance, authentic native appearance, and tight integration. In contrast, Swing prioritizes a customizable and consistent look regardless of platform differences.
The design principles behind SWT were influenced by Erich Gamma, known for his work on Design Patterns, resulting in a simpler framework than Swing. While this simplicity reduces complexity for developers, it also means SWT offers fewer features compared to Swing.
James Gosling, creator of Java, has observed that SWT’s straightforwardness poses challenges for cross-platform porting—similar to early issues faced by AWT—due to its close dependency on the Win32 GUI API.
Although SWT does not inherently include a built-in model–view–controller (MVC) architecture common in Swing and other frameworks, the related JFace library within the Eclipse project provides a cross-platform MVC abstraction at a higher level. Developers can utilize JFace for adaptable data models in complex controls like trees and tables or interact directly with SWT controls when needed.
Look and feel
SWT widgets exhibit the same look and feel as their native counterparts since they frequently utilize the actual native components. This differs from the Swing toolkit, where widgets are simulated versions of native elements. For instance, the macOS tree widget includes delicate animations and glowing pulses on buttons, features that are missing from Swing’s default implementations.
Being a wrapper around native GUI code, SWT demands fewer modifications when operating systems evolve, as long as OS providers keep their APIs stable. Conversely, Swing depends on "pluggable looks and feels"—themes that require updates to align with changes in the OS graphical interface.
SWT emphasizes "deep platform integration," allowing for close interaction with the native platform. This is advantageous for developers needing tight OS coupling; for example, SWT can encapsulate ActiveX controls on Microsoft Windows.
Programming
A simple SWT "Hello, World!" example involves creating a window (Shell) along with a label:
<syntaxhighlight lang="java"> import org.eclipse.swt.*; import org.eclipse.swt.widgets.*;
public class HelloWorld {
public static void main (String[] args) {
Display display = new Display();
Shell shell = new Shell(display);
Label label = new Label(shell, SWT.NONE);
label.setText("Hello, World!");
label.pack();
shell.pack();
shell.open();
while (!shell.isDisposed()) {
if (!display.readAndDispatch()) display.sleep();
}
display.dispose();
}
} </syntaxhighlight>
Unlike Swing, SWT requires direct handling of the Display object to interact with OS resources, which must be explicitly released when no longer in use.
Platform support
Because SWT must be adapted for each GUI library it supports, it is not available on every platform where Java runs and may perform less optimally outside of Windows. Since SWT relies on native libraries specific to each platform, applications might encounter bugs unique to certain environments.
By exposing more low-level functionality than Swing, SWT offers a thin user-interface API intended for consistent implementation across platforms while still supporting complex GUI applications.
Each supported platform necessitates its own SWT library (JAR file) to be included with the application.
As of now, SWT supports these platforms and GUI toolkits:
- Windows:
- Win32
- Windows Presentation Foundation (WPF) – currently in development
- Unix-like:
- macOS:
The official support in SWT versions 4.7.3a and 4.8M6 includes:
- Microsoft Windows (x86 and x86_64)
- Linux (GTK / PPC64 and PPC64LE)
- macOS (Cocoa / x86_64)
Previously supported environments encompass Windows XP, Linux on s390, Solaris 11 (SPARCv9), Solaris 10 (x86_64), HP-UX (ia64), and AIX (PPC and PPC64).
Performance
SWT was engineered as a high performance GUI framework with goals to deliver faster responsiveness and lower resource consumption compared to Swing. Benchmark tests have yielded varied outcomes: while SWT can provide superior efficiency in certain settings (such as Windows), Swing may outperform SWT in others (for example, Linux or Windows under VMware). Overall, neither toolkit consistently dominates in performance across all scenarios.
Extensibility and Comparison with Other Java Toolkits
Because SWT depends heavily on native code, extending many of its widget classes through inheritance can be challenging, which may limit flexibility when compared to Swing. Custom widget development in SWT generally involves more complexity, particularly when aiming for compatibility across multiple platforms. Although both SWT and Swing allow developers to build new widgets entirely in Java, SWT requires additional effort to maintain consistent behavior across different operating systems.
In contrast to most Java GUI frameworks, SWT mandates explicit resource management; programmers need to invoke the dispose method manually to release native resources. Neglecting this step can cause memory leaks or other resource-related problems. While this approach grants finer control over resource handling, it introduces added complexity and potentially higher development overhead compared to Swing’s automatic garbage collection. This requirement arises because SWT uses native resources that the JVM’s garbage collector does not automatically manage.
Development
Efforts to bridge Swing and SWT have produced two primary strategies:
- SwingWT implements an alternative version of Swing backed by SWT, merging SWT’s native appearance and performance benefits with the familiar Swing programming paradigm.
- SWTSwing acts as a Swing backend for SWT, allowing SWT applications to run on all platforms supported by Swing by substituting platform-specific native objects with those provided by Swing.
Since 2006, the DWT initiative has adapted SWT version 3.2 for the D programming language, supporting 32-bit Windows and Linux GTK environments for SWT 3.4. This project also includes ports of JFace and Eclipse Forms extensions.
With JavaFX becoming part of the standard Java SE environment, projects like SWT on JavaFX, integrated into e(fx)clipse since 2014, focus on creating an SWT backend built on JavaFX technology, paralleling how SWTSwing leverages Swing components.
Applications
Prominent software utilizing SWT includes:
- Apache Directory Studio (an LDAP browser and editor)
- The Eclipse IDE along with its extensive plugin ecosystem
- GumTree Platform (a scientific research workbench)
- Haystack (an information management system)
- IBM Rational Software suite: Rational Application Developer, Rational Software Architect, Rational Team Concert
- IBM Lotus products: Notes, Sametime, Symphony, Expeditor
- Studio 3T (a graphical interface for MongoDB)
- RSSOwl (an RSS feed aggregator)
- SmartGit (a client supporting Git, Mercurial, and SVN)
- TuxGuitar (a tablature editor)
- uDig (a geographic information system tool)
- Vuze (formerly known as Azureus)
The Eclipse community has also developed the Eclipse Remote Application Platform (RAP), which adapts SWT and JFace for web applications by integrating the qooxdoo Ajax framework with the SWT API. This facilitates rapid web app creation using SWT concepts similar to desktop development and complements other Java-based Ajax frameworks such as Echo2, Vaadin, and Google Web Toolkit.
See also
References