Standard Widget Toolkit

From Wikipedia, the free encyclopedia

The Standard Widget Toolkit (SWT) is a graphical widget toolkit for the Java platform originally developed by IBM and maintained now 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 standard.

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.^[1]

Contents 1 Java GUI toolkit history 2 Design 3 Performance 4 Look and feel 5 Extensibility and comparison to other Java code 6 SWT platform support 7 SWT applications 8 SWT documentation 9 Development 10 References 11 External links

[edit] Java GUI toolkit history

AWT (the Abstract Windowing Toolkit) was the first Java GUI toolkit, introduced with JDK 1.0 as one component of the Sun Microsystems Java standard. The relatively primitive AWT wrapped Java code around native (operating system-supplied) objects to create GUI elements, such as menus, windows and buttons. AWT was a very thin wrapper around native widgets, exposing developers to platform specific code, quirks and bugs that limited how portable and native-looking applications could be across different computing platforms.

Swing was the next generation toolkit introduced by Sun into J2SE 1.2, and was more object-oriented than AWT. Swing GUI elements are 100% Java, with no native code — instead of wrapping around native APIs, Swing calls low level operating system routines to draw the GUI elements by itself.

Around this time, IBM was developing their VisualAge development integrated development environment (IDE), coded 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.^[2]

[edit] 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, similarly 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.

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."^[3]

It has been argued that SWT features a clean design, in part inspired by Erich Gamma of Design Patterns fame.^[4]

SWT is a relatively simpler toolkit than Swing, with less (possibly) extraneous functionality for the average developer.^[5] This has lead some people to argue that SWT lacks functionality when compared to Swing.^[6]

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.^[5]

Mauro Marinillia at developer.com argues that "SWT may seem simpler to use than Swing because it spares developers from a lot of sophisticated issues (such as the elaborated Swing class hierarchy, pluggable look and feel, the Model-View-Controller approach, and so on)". With that said, some may feel that an enforcement of some of these complex issues (especially Model-View-Controller) is a good thing, forcing correct practices. Marinillia also argues that "[compared to SWT] Swing provides a larger set of features, it is much more elegant, and gives [a] higher abstraction level (that turns helpful when developing complex GUIs with custom components)" and that "in general, SWT is easier to use at first, but when it comes to building complex GUIs, Swing usually [provides] results [that] are easier to use and more flexible".

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.

[edit] Performance

SWT is designed to be a "high performance" GUI toolkit; faster, more responsive and lighter on system resource usage than Swing.^[7] There has been some attempted benchmarking of SWT and Swing, which concluded that SWT is 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.^[8]

[edit] 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 Swing version of these widgets do not animate.

Since SWT is simply a wrapper around native GUI code, it should not require large amounts of updates when that native code is changed (provided that the API remains the same). 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".^[9] This deep integration can be useful in a number of ways, for example enabling SWT to wrap ActiveX objects on Microsoft Windows.

[edit] 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.^[9] 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, 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".^[10] 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." ^[9] 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.

[edit] SWT platform support

SWT will not necessarily run on every platform that Java supports, as SWT uses wrappers around platform specific libraries to display GUI elements. This means that SWT must be ported to every new GUI library that needs supporting, and SWT is not freely available on a platform as soon as Java is ported to it (as Swing and AWT are). There is also some evidence that the performance of SWT on platforms other than Windows is noticeably less efficient.^[6]

Since SWT uses a different native library for each platform, SWT developers may be exposed to platform specific bugs, thus neutralizing the Java "Write Once, Run Everywhere" advantage, by requiring them to write platform specific code. SWT has been referred to as a "Write Once, Test Everywhere" solution, similar to those provided by languages such as C.^[11]

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." ^[12]

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

It is argued that SWTs minimalist use of other Java class libraries (including the fact that it makes no use of AWT) enable it to be used with an older JDK (such as 1.1.8) or on a handheld computer which may not feature the entire Java class library.

As of March 2006 SWT supports the following platforms and / or GUI libraries:

• Microsoft Windows using the 32-bit Java VM
• AIX, FreeBSD, Linux, HPUX:
  • Motif
  • GTK+
• Mac OS: Carbon
• QNX Photon
• Pocket PC
• Swing (via SWTSwing)

[edit] SWT applications

Applications using SWT include:

• Azureus
• Eclipse and its plugins
• Eclipse Trader (stock tool)^[13]
• GumTree Platform (scientific workbench)
• Haystack (information manager)
• Hetman file manager^[14]
• jLibrary Content Management System
• Panoptes (graphical JMX manager)^[15]
• RSSOwl feed aggregator
• Sancho (P2P GUI)^[16]
• uDig GIS tool
• Xinity BASE^[17]

[edit] SWT documentation

As a younger GUI toolkit than Swing, SWT is less extensively documented (in terms of number of books covering the subject) than Swing.^{[citation needed]}

SWT: The Standard Widget Toolkit is the definitive SWT guide according to the Eclipse Foundation.^[18] Other books which cover SWT include:

• Rob Warner, Robert Harris (2004). The definitive guide to SWT and JFace. Apress. 
• Eric Clayberg and Dan Rubel (2004). Eclipse: Building commercial-quality plug-in. Addison-Wesley. 
• Erich Gamma and Kent Beck (2004). Contributing to Eclipse. Addison-Wesley. 
• Sherry Shavor et al (2004). The Java Developers Guide to Eclipse. Addison-Wesley. 

[edit] 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:

• The Eclipse project is working towards allowing Swing widgets to be embedded inside SWT container widgets (Swing widgets can currently be embedded inside AWT widgets, and this is in fact the normal way of doing things for Swing).^{[citation needed]}
• SwingWT is a project which intends to provide Swing developers with an alternative Swing implementation – one which uses an SWT backend to display its widgets, thus providing the native look and feel and performance advantages of SWT along with the same programming model as Swing.^[19]
• SWTSwing is a project which intends to provide a Swing backend 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, thus improving SWTs cross-platform support.^[20]

[edit] References

[edit] External links

• SWT main page
• SWT newsgroup. The newsgroup is password protected; the password is available from here.
• Eclipse applications
• Eclipse applications, part 2
• Further information on SWT
• Information on Eclipse, including SWT information within a "platform plug-in developer guide"
• SWT Javadoc API documented at eclipse.org