Standard Widget Toolkit

Infobox Software
name = Standard Widget Toolkit



caption = The Eclipse IDE, an SWT-based application
developer = Free software community
latest release version = 3.4
latest release date = release date|2008|06|17
latest preview version = 3.5 M1
latest preview date = release date|2008|08|07
operating system = Cross-platform
language = Multilingual
genre = widget toolkit for the Java platform
license = Eclipse Public License
website = http://www.eclipse.org/swt/

The Standard Widget Toolkit (SWT) is a graphical widget toolkit for use with the Java platform. It was originally developed by IBM and is now maintained by the Eclipse Foundation in tandem with the Eclipse IDE. It is an alternative to the AWT and Swing Java GUI toolkits provided by Sun Microsystems as part of the Java Platform, Standard Edition.

SWT is written in Java. To display GUI elements, the SWT implementation accesses the native GUI libraries of the operating system using JNI (Java Native Interface) in a manner that is similar to those programs written using operating system-specific APIs. Programs that call SWT are portable, but the implementation of the toolkit, despite the fact that it is written in Java, is unique for each platform.

The toolkit is licensed under the Eclipse Public License, an Open Source Initiative approved open source license. [cite web | author = Open Source Initiative | title = Licenses By Name | url = http://www.opensource.org/licenses/ | accessdate = 2007-03-24]

Java GUI toolkit history

AWT (the Abstract Window Toolkit) was the first Java GUI toolkit, introduced with JDK 1.0 as one component of the Sun Microsystems Java platform. The original AWT was a simple Java wrapper around native (operating system-supplied) widgets such as menus, windows and buttons.

Swing was the next generation GUI toolkit introduced by Sun in J2SE 1.2. Swing was developed in order to provide a richer set of GUI components than AWT. Swing GUI elements are 100% Java with no native code: instead of wrapping native GUI components, Swing draws its own components by using Java2D to call low level operating system drawing routines.

The roots of SWT go back to work that Object Technology International, or OTI, did in the 1990s when creating multiplatform, portable, native widget interfaces for Smalltalk (originally for OTI Smalltalk, which became IBM Smalltalk in 1993). IBM Smalltalk's Common Widget layer provided fast, native access to multiple platform widget sets while still providing a common API without suffering the "lowest common denominator" (LCD) problem typical of other portable graphical user interface (GUI) toolkits. IBM was developing their VisualAge development integrated development environment (IDE) that was written in Smalltalk. They decided to open-source the project, which led to the development of Eclipse, intended to compete against other IDEs such as Microsoft Visual Studio. Eclipse is written in Java, and IBM developers, deciding that they needed a toolkit that had "native look and feel" and "native performance", created SWT as a Swing replacement [cite web | title = FAQ: Why does Eclipse use SWT? | url = http://wiki.eclipse.org/FAQ_Why_does_Eclipse_use_SWT%3F | accessdate = 2007-03-24] .

Design

SWT is a wrapper around native code objects, such as GTK+ objects, Motif objects etc. Because of this, SWT widgets are often referred to as "heavyweight", evoking images of a light Java wrapper around a "heavy" native object. In cases where native platform GUI libraries do not support the functionality required for SWT, SWT implements its own GUI code in Java, similar to Swing. In essence, SWT is something of a compromise between the low level performance and look and feel of AWT and the high level ease of use of Swing [cite web | author = Steve Northover | title = SWT: Implementation Strategy for Java™ Natives | url = http://www.eclipse.org/articles/Article-SWT-Design-1/SWT-Design-1.html | accessdate = 2001-03-22] [cite web | author = Carolyn MacLeod and Steve Northover | title = SWT: Managing Operating System Resources | url= http://www.eclipse.org/articles/swt-design-2/swt-design-2.html | accessdate = 2001-11-27] .

According to the Eclipse Foundation, "SWT and Swing are different tools that were built with different goals in mind. The purpose of SWT is to provide a common API for accessing native widgets across a spectrum of platforms. The primary design goals are high performance, native look and feel, and deep platform integration. Swing, on the other hand, is designed to allow for a highly customizable look and feel that is common across all platforms."cite web | title = FAQ: Is SWT better than Swing? | url = http://wiki.eclipse.org/FAQ_Is_SWT_better_than_Swing%3F | accessdate = 2008-02-16]

It has been argued that SWT features a clean design, in part inspired by Erich Gamma of Design Patterns fame. [cite web | author = Ben Galbraith | title = An Introduction to SWT | url = http://www.javalobby.org/eps/swt_intro/ | accessdate = 2007-03-24]

SWT is a relatively simpler toolkit than Swing, with less (possibly) extraneous functionality for the average developer.cite web | author = Ella Morton | title = James Gosling Q & A | url = http://www.builderau.com.au/program/work/0,39024650,39176462,00.htm | accessdate = 2007-03-24] This has led some people to argue that SWT lacks functionality when compared to Swing.cite web | title = Performance Benchmarks of Nine Languages | url = http://developers.slashdot.org/article.pl?sid=04/01/09/1340223 | accessdate = 2007-03-24]

James Gosling, the creator of the Java language, has argued that SWT is too simple, and that SWT is a difficult toolkit to port to new platforms for the same reason that AWT used to have porting platforms – that it is too simple, too low level, and too tied to the Win32 GUI API, leading to problems adapting the SWT API to other GUI toolkits, such as Motif and OS X Carbon.

Although SWT does not implement the popular Model-View-Controller architecture used in Swing and many other high level GUI toolkits, the JFace library, which is developed as part of the same Eclipse project, does provide a platform-independent, higher-level Model-View-Controller abstraction on top of SWT. Developers may choose to use JFace to provide more flexible and abstract data models for complex SWT controls such as trees, tables and lists, or access those controls directly as needed.

Performance

SWT was designed to be a "high performance" GUI toolkit; faster, more responsive and lighter on system resource usage than Swing. [ cite web | url = http://weblogs.java.net/blog/aiqa/archive/2004/11/why_i_choose_sw.html | title = Why I choose SWT against Swing | first = Ozgur | last = Akan | date = November 19 2004 | accessdate = 2006-11-07 ] There has been some attempted benchmarking of SWT and Swing, which concluded that SWT was more efficient than Swing, although the applications benchmarked in this case were not complex enough to draw solid conclusions for all possible SWT or Swing uses. [ [http://www.javalobby.org/java/forums/t65168.html Swing vs. SWT Performance - Have a Look at the Call Stacks ] ] . More "real-life" benchmarks show no clear winner, and showed that the results greatly depend on the context and the environments [cite web
url=http://cosylib.cosylab.com/pub/CSS/DOC-SWT_Vs._Swing_Performance_Comparison.pdf
title=SWT Vs. Swing Performance Comparison
quote="Initial expectation before performing this benchmark was to find SWT outperform Swing. This expectation stemmed from greater responsiveness of SWT-based Java applications (e.g., Eclipse IDE) compared to Swing-based applications. However, this expectation could not be quantitatively confirmed."
first=Križnar|last=Igor
publisher=cosylab.com
date=2005-05-10
accessdate=2008-05-24] .

Look and feel

SWT widgets have the same "look and feel" as native widgets because they often are the same native widgets. This is in contrast to the Swing toolkit where the widgets are close copies of the native widgets. In some cases the difference is distinguishable. For example the Mac OS X tree widget features a subtle animation when a tree is expanded and default buttons actually have an animated pulsing glow to focus the user's attention on them. The default Swing version of these widgets do not animate.

Since SWT is simply a wrapper around native GUI code, it does not require large amounts of updates when that native code is changed, providing that operating system vendors are careful not to break clients of their API when the operating systems are updated. The same cannot be said of Swing — Swing supports the ability to change the look and feel of the running application with "pluggable look and feels" which enable emulating the native platform user interface using themes, which must be updated to mirror operating system GUI changes (such as theme or other look and feel updates).

SWT aims for "deep platform integration", the Eclipse reference to SWT's use of native widgets. According to Mauro Marinillia of developer.com, "whenever one needs a tight integration with the native platform, SWT can be a plus". cite web | title = Swing and SWT: A Tale of Two Java GUI Libraries | url = http://www.developer.com/java/other/article.php/2179061 | first = Mauro | last = Marinilli | accessdate = 2006-11-07 ] This deep integration can be useful in a number of ways, for example enabling SWT to wrap ActiveX objects on Microsoft Windows.

Extensibility and comparison to other Java code

Due to the use of native code, SWT classes do not allow for easy inheritance for all widget classes, which some people consider can hurt extensibility. This can make customizing existing widgets more difficult to achieve with SWT than if one were using Swing. Both toolkits support writing new widgets using only Java code.

SWT widgets, unlike almost any other Java toolkit, requires manual object deallocation, as opposed to the standard Java practice of automatic garbage collection. SWT objects must be explicitly deallocated using the ".dispose()" function, which is analogous to the C language's "free". [The Java developers guide to Eclipse, 2nd ed., p359] If this is not done, memory leaks or other unintended behavior may result. On this matter, some have commented that "explicitly de-allocating the resources could be a step back in development time (and costs) at least for the average Java developer." and that "this is a mixed blessing. It means more control (and more complexity) for the SWT developer instead of more automation (and slowness) when using Swing." The need for manual object deallocation when using SWT is largely due to SWT's use of native objects. As these objects are not tracked by the Java JVM, the JVM is unable to ascertain whether or not these native objects are in use, and thus unable to garbage collect them at an appropriate time.

In practice, the only SWT objects which a developer must explicitly dispose are the subclasses of Resource, such as Image, Color, and Font objects. Fact|date=April 2007

Example

The following is a basic Hello World program using SWT. It shows a window ("Shell") and a label.

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 ();

Contrary to Swing (Java), a "Display" class is necessary to access the underlying Operating system, and its resources must be explicitly disposed of when they are no longer used.

Platform support

SWT must be ported to every new GUI library that needs supporting. Therefore, unlike Swing, it is not freely available on a platform as soon as Java is ported to it since Swing and AWT are normally part of every Java port, while SWT is not. There is also some evidence that the performance of SWT on platforms other than Windows is noticeably less efficient. Since SWT uses a different native library for each platform, SWT developers may be exposed to platform specific bugs, rather than a common set, found in Swing and fixed by Sun.

SWT exposes developers to more low level details than Swing. This is because SWT is technically just a layer over native library provided GUI functionality – that said, exposing the programmer to native GUI code seems to be part of the design intent of SWT: "Its goal is not to provide a rich user-interface design framework but rather the thinnest possible user-interface API that can be implemented uniformly on the largest possible set of platforms while still providing sufficient functionality to build rich graphical user interface (GUI) applications." [ [http://wiki.eclipse.org/index.php/FAQ_What_is_SWT%3F FAQ What is SWT - Eclipsepedia ] ]

Since the SWT implementation is different for each platform, a platform specific SWT (JAR file) must be distributed with each application.

As of July 2008 SWT supports the following platforms and / or GUI libraries:

* Windows XP, Windows Vista:
** Win32
** WPF (under development)
* AIX, FreeBSD, Linux, HP-UX:
** Motif
** GTK+
* Mac OS X:
** Carbon
** Cocoa (under development)
* QNX Photon
* Pocket PC

Applications

Applications using SWT include:

* Vuze, formerly known as Azureus
* Eclipse and its plug-ins
* GumTree Platform (scientific workbench)
* Haystack (information manager)
* RSSOwl feed aggregator
* uDig GIS tool

Use on the web

Recent open source efforts in the eclipse community have led to a porting of SWT (and JFace) into a widget toolkit appropriate for the web. The result has been the Eclipse RAP, which combines the qooxdoo AJAX library with the SWT API. Like other Java AJAX projects (such as Echo2 and Google Web Toolkit), the usage of the SWT API allows developers to quickly develop applications for the web in much the same way as they would for the desktop.

Use outside Java

Since January 2008, SWT has been available for C++, which is called SWT C++, from PureNative Software. SWT C++ is implemented in 100% native C++, for C++ development. SWT C++ runs without a Java Runtime Environment (JRE), and therefore does not use JNI. SWT C++ is made possible by NewJ [ [http://www.pure-native.com/newj.html NewJ - The core Java APIs in C++, for C++] ] Desktop for C++, which is a 100% native C++ implementation of the core Java APIs, and SWT Camp [ [http://www.pure-native.com/swtcpp/swtcamp.html SWT Camp - The SWT C++ Do-It-Yourself Kit] ] , a developer kit for producing SWT C++ from the SWT Java implementation source code. Presently, SWT C++ is only supported for Microsoft Windows and Microsoft Visual C++ 7.1 (Visual Studio 2003).

Starting in 2006 there was a SWT-3.2 port to the D programming language called DWT. [ [http://www.dsource.org/projects/dwt DWT - Port of SWT and friends to the D programming language] ] Since then the project supports Windows 32-bit and also Linux GTK 32-bit for SWT-3.4. The DWT project also has an addon package that contains a port of JFace and Eclipse Forms. [ [http://www.eclipse.org/articles/Article-Forms/article.html Eclipse Forms] ]

Development

There is some activity to "unify" Swing and SWT, largely due to the popularity of Eclipse.

There are several different approaches being attempted to integrate Swing and SWT:

* "SwingWT" is a project which intends to provide Swing developers with an alternative Swing implementation – one which uses an SWT back end to display its widgets, thus providing the native look and feel and performance advantages of SWT along with the same programming model as Swing. [ [http://swingwt.sourceforge.net/ SwingWT - The Swing/AWT API over SWT library ] ]
* "SWTSwing" is a project which intends to provide a Swing back end for SWT. In effect, SWT could be run using "Swing native objects" instead of, for example, GTK or Windows native objects. This would enable SWT to work on every platform that Swing supports. [ [http://swtswing.sourceforge.net Refresh ] ]

See also

* List of widget toolkits

References

Documentation

*
*
*
*
*

External links

* [http://www.eclipse.org/swt/ SWT main page]
* [news://news.eclipse.org/eclipse.platform.swt SWT newsgroup] . The newsgroup is password protected; the password is available from [http://dev.eclipse.org/newsManager/newsRequestForm.html here] .
* [http://www.oneclipse.com/Members/admin/news/swt-sightings/ Eclipse applications]
* [http://www.oneclipse.com/Members/admin/news/swt-sightings-vol-2/ Eclipse applications, part 2]
* [http://wiki.eclipse.org/index.php/FAQ_Where_can_I_find_more_information_on_SWT%3F Further information on SWT]
* [http://www.eclipse.org/documentation/main.html Information on Eclipse] , including SWT information within a "platform plug-in developer guide"
* [http://help.eclipse.org/help31/nftopic/org.eclipse.platform.doc.isv/reference/api/org/eclipse/swt/package-summary.html SWT Javadoc API] documented at eclipse.org