-Head First Java
SWT (Standard Widget Toolkit) is a graphics library and a widget toolkit integrated with the native window system (especially with Windows but Linux and Solaris are supported as well). Despite the tight integration with the native target platform, SWT is an OS-independent API. SWT can be seen as a thin wrapper over the native code GUI of the host operating system.
At a higher level of abstraction, also a part of the Eclipse platform, lies JFace. This is a GUI library, implemented using SWT, that simplifies common GUI programming tasks. JFace is independent of the given window system, in both its API and implementation, and is designed to work with SWT, without hiding it.
SWT is originally from IBM, now being developed by the Eclipse Foundation.
Eclipse is an open-source, IBM-sponsored, fully extensible IDE, built using Java and SWT. SWT originated as Eclipse's GUI library, but it can be used outside it as a an alternative GUI library to both Sun's AWT and Swing.
Note: Swing(The reference GUI toolkit for J2SE) is a graphics library for Java. Swing is one part of the Java Foundation Classes (JFC). Swing includes graphical user interface (GUI) widgets such as text boxes, buttons, split-panes, and tables.
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 yet succeeded.
Criticisms of SWT
Critics of the SWT toolkit point out that:
1. Performance of Swing is improving with every release and on certain platforms the balance of toolkit speed is very much in Swing's favour;
2. 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;
3. 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.
4. 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.)
The battle of the Java GUIs is far from over...
SWT Sightings - Volume 1
Swing Sightings Index