Standard Widget Toolkit

The SWT (or Standard Widget Toolkit) is a framework for developing graphical user interfaces in Java. Developed by the Eclipse Foundation for the Eclipse IDE, it represents the third main option for developers when creating desktop applications to execute on the Java platform. It uses explicitly standard Java, with the approved Java Native Interface, but the toolkit cannot be described as "pure" because of the reliance on a platform-native library for every computer on which it runs. While Java is clearly dominant on server and mobile platforms where the user interface paradigm is either highly controlled or easily subsumed, detractors of Java generally point out that where a rich desktop environment is in use, Java has not had a similar impact.

Contents

1 Arguments in favour of SWT development

2 Criticisms of SWT

3 History

4 Solutions to the reunification of the Java desktop standards

5 External links

Arguments in favour of SWT development

Those who support SWT observe that:

When developers of an operating system change its look and feel, Swing must be manually updated to match the changes. This tends to cause Swing's look-and-feel to lag behind that of the native operating system.
Despite the fact that it might be possible for Swing to support native operating system themes, this support has not been fully implemented. Consequently, when an end-user chooses an operating-system theme other than the default, Swing applications will look and feel different from the rest of the applications on that computer.
End-users can often detect when an application is written using Java and Swing. The same is not true of applications written using Java and SWT unless the developers go out of their way to make their application look or feel different from native applications. (Recently, the Eclipse 3.0 developers have done this.)

As a consequence of the above, SWT proponents contend that:

Having a native look-and-feel by default enables SWT applications to be accepted by customers who want all of their applications to look and behave the same way.
Consequently, SWT gives Java a second opportunity to succeed as a platform for creating rich-client desktop applications where Swing has not yet succeeded.

Some additional observations have been made:

Performance of Swing is hindered by an excessive amount of "object churn", creation and immediate obsolescence of large amounts of local objects.

Some open-source software distributions do not include closed-source toolkits. While the source to Java is available, this is under a license that does not permit unrestrained modification. To get around this, the GCJ compiler can be used to create executables. While GCJ can use external libraries (such as that required by SWT), it is not as yet capable of compiling Swing. Thus, those who wish to create Java desktop applications using a fully open-source software stack have no choice but to use SWT.

Criticisms of SWT

Critics of the SWT toolkit point out that:

Performance of Swing is improving with every release and on certain platforms the balance of toolkit speed is very much in Swing's favour;
Swing has completely extensible platform support and improving the look-and-feel is perfectly possible by end-users. There is no theoretical reason why Swing should lag behind operating system support generally, since the files needed by the system to determine the installed theme can equally easily be read by Swing. For demonstration, the Eclipse IDE has been rendered (http://www.jgoodies.com/freeware/metamorphosis/) in Swing;
The programming model of SWT inherits strongly from that of a traditional Microsoft Windows application. This makes it extremely challenging to create a high-quality, highly-performant port of SWT itself to new windowing systems. Although a few of these ports do exist, only extremely talented programmers have been able to create them.
In order to support SWT as a part of the standard Java Development Kit, every Java licensee would have to include a SWT native library. For platforms that do not already have a port of SWT, this would present a significant barrier to entry. (For platforms that already have an SWT port, Java licensees could simply bundle the existing SWT port since SWT is developed under a commercially-friendly open-source license.)

Nevertheless, creating a small layer over a platform native resource is not unprecedented in Java. Hardware APIs such as that of serial or USB support simply provide a Java calling convention for the underlying hardware. In the 3D space, JOGL provides low level access for game developers with Java3D providing a higher level scene graph API. SWT has a comparable higher-level JFace API, layered onto SWT but without "hiding" it, to provide classes and functions to handle common tasks associated with programming using SWT.

History

IBM possessed a Java integrated development tool called Visual Age for Java. This product was open-sourced and led to the development of the Eclipse platform, with the stated intent of competing with Microsoft's Visual Studio. Rumour has it that the naming was intended to imply an "eclipse of the Sun", referring to Sun Microsystems, the developer and standards-steward of Java through the Java Community Process.

The AWT (or Abstract Window Toolkit) was the first user interface toolkit for Java. It used native peers (as does SWT) but adopted a "lowest common denominator" approach whereby widgets that were not available reliably on all platforms were not included. This was nevertheless largely suitable for the Web applet objectives of early Java versions.

Swing (or the Java Foundation Classes) were the next generation of toolkit and built on a far more contemporary object-oriented framework. Swing differs from AWT in that only a minimal amount of support is required from the host platform (basically, to provide a window). All drawing of widgets is then done from within the JRE. This allows new looks-and-feels to be plugged in during program execution. It also ensures that a desktop environment needs almost no code written to provide basic Swing support. If a Java runtime environment is available, then a default look-and-feel may be rendered enabling an application to be used.

A letter (http://www.mail-archive.com/jug-discussion@tucson-jug.org/msg00355.html) reputed to come from a Visual Age developer but later investigated (http://javalobby.org/thread.jspa?forumID=61&threadID=7034&start=0&mode=flat) as a fraud nevertheless describes some possible background to the development of SWT. Swing remains the Java-standard graphic toolkit but whilst accepting the politically charged nature of SWT, proponents sometimes regard it as a sort of "AWT 2" where the graphical peer layer of Java (still available for legacy reasons) is replaced by a more modern equivalent.

Solutions to the reunification of the Java desktop standards

Because of the penetration of Eclipse in the IDE marketplace and the correspondingly high developer awareness of SWT, moves at various levels have begun to rejoin what at face value appears to be a schism.

Oracle Corp. announced JSR 198 to unify the API for plug-in developers to ensure they need only write one plug-in to be able to target all Java IDEs. At the same time a Java Tool Community (http://www.javatools.org) was invoked in order to drive standards adoption. At present Eclipse has declined to join. Sun has vacillated on whether to join the Eclipse board given its existing investment in NetBeans.

Three technical integration methodologies are being pursued:

Eclipse is developing a methodology to allow Swing widgets to be embedded in SWT containers (as they are in AWT presently);
SwingWT (http://swingwt.sourceforge.net/) provides Swing developers with the option to plug-in SWT at the back-end as a type of Swing look-and-feel (thus obviating the programming model criticism of SWT);
SWTSwing (http://chrriis.brainlex.com/projects/swtswing/) provides SWT developers with the option to run with Swing as the "native platform" (thus obviating the platform dependence criticism of SWT).