What is SWT?

The Standard Widget Toolkit (SWT) is an open source framework for developing graphical user interfaces in Java. It is developed by the Eclipse Foundation for the Eclipse IDE, and licensed under the Eclipse Public License. It represents an alternative to AWT and Swing for developers creating desktop Java applications. It is written in standard Java, and accesses platform-specific libraries through the Java Native Interface, which is considered a primary strength, despite not being pure Java.

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.

Arguments in favour of SWT development
Those who support SWT observe that:

1. 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.
2. 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.
3. 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:

1. 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.
2. Consequently, SWT gives Java a second opportunity to succeed as a platform for creating rich-client desktop applications where Swing has not been that successful.

Some additional observations have been made:

1. Performance of Swing is hindered by an excessive amount of "object churn", creation and immediate obsolescence of large numbers of local objects.
2. Also, for a long time Swing has been distributed under a proprietary closed-source source code license. That is, while the source code is available to read, programmers cannot redistribute it outside of an approved Java Runtime Environment (JRE). Only recently the GNU Classpath project started to offer the alternative open source Swing implementation.
3. SWT is distributed under an open-source license, permitting it to be used and distributed as a part of any program a programmer may wish to create. SWT programmers have also recently been reimplementing the Swing API on top of SWT in the SwingWT project.

Criticisms of SWT
Critics of the SWT toolkit point out that:

1. SWT performance on non Windows platforms lags behind that on Windows, and on some platforms such as Mac OS X, Swing is perceived to have better performance than SWT.
2. Swing has completely extensible platform support and improving the look-and-feel is 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 in Swing.
3. 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.)
4. The maintenance and development of SWT is driven by the needs of the Eclipse project. Hence, fixes for obscure bugs can take a long time to be released
5. The SWT/AWT bridge is non functional on Mac OS X. This is only a problem when mixing SWT and Swing in the same application.

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.

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 reputed to come from a Visual Age developer but later investigated 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.

About this Terminology
This terminology is from The Wikipedia which is published under the GNU Free Documentation License.