Standard Widget Toolkit

From Free net encyclopedia

Template:RRevised

SWT is the "Standard Widget Toolkit" (an open source Graphical User Interface toolkit) for Java (although it is not a Sun Microsystems Java standard). It is an open source alternative to AWT and Swing, the two other Java GUI toolkits (both of which are proprietary Sun Microsystems Java toolkits). SWT accesses native code GUI libraries through JNI (the Java Native Interface) to display its GUI widgets. [1]

Contents

[edit]

Java GUI toolkit history

Template:Splitsection

AWT (the Abstract Windowing Toolkit) was the first Java GUI toolkit, introduced with J2SE 1.0 as one component of the Sun Microsystems Java standard. The relatively primitive AWT wrapped Java code around native (operating system or platform supplied) objects to create GUI elements, such as menus, windows and buttons. Many people claim that AWT was a poor toolkit, as it was a very thin wrapper around native widgets, exposing developers to more platform specific code, quirks and bugs than was necessary (especially given that Java is intended to be a "Write Once, Run Anywhere" language). It has been claimed that AWT was "conceptualized and implemented in only one month" Template:Citation needed which may partly or wholly be the reason for its alleged mediocrity.

Swing was a "next generation" (some would claim "replacement") official Sun Microsystems Java GUI toolkit as of J2SE 1.2, and was more object-oriented, more comprehensive, more complex, less difficult to use, less difficult to debug and generally more advanced than AWT. Swing GUI elements are 100% Java, with no native code - instead of wrapping around native GUI element code, Swing calls low level Operating System rendering routines to draw the GUI elements by itself.

Around this time, IBM was developing their VisualAge development IDE, coded in SmallTalk. They decided to open-source the project, which led to the development of Eclipse, an IDE which is intended to compete against other IDEs such as Microsofts 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]

SWT was thus introduced as an alternative to the two Sun Microsystems offical GUI toolkits, and is something of a compromise between the two - reasonably high level like Swing, but still a wrapper around native GUI elements like AWT (leading some to refer to SWT as "AWT2"). There is an email purporting to explain the history of SWT at http://www.mail-archive.com/jug-discussion@tucson-jug.org/msg00355.html, however there is some contention over its factual accuracy.

[edit]

Introduction to SWT

SWT is the "Standard Widget Toolkit" (a Graphical User Interface toolkit) for Java (although it is not a Sun Microsystems Java standard, despite the name). It is an alternative to AWT and Swing, the two other Java GUI toolkits (both of which are proprietary Sun Microsystems Java libraries).

SWT is one of 3 GUI toolkits for Java:

  1. AWT
  2. Swing
  3. SWT

SWT is developed by the Eclipse Foundation (IBM, Intel, Borland, Computer Associates, etcetera) [3], and is developed specifically for Eclipse. As such the use of SWT is tied into Eclipse development – those who develop plugins for Eclipse need to use some SWT for the plugins GUI (should it exist) at some stage. It is however quite possible to use SWT outside of Eclipse [4].

SWT is licensed under the Eclipse Public License (an Open Source Initiative approved open source license [5]). Most of the official Java libraries (including Swing) are proprietary Sun Microsystems code (however, see the GNU Classpath project, an attempt to create a fully open source Java library).

SWT is written in Java, and to display GUI elements SWT accesses platform specific (native code) GUI libraries through JNI, the Java Native Interface. Thus SWT is a wrapper around native code objects, such as GTK objects, Motif objects etcetera. Because of this, SWT widgets are often refered 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.

JFace is another toolkit, introduced to enable easier, platform independent usage of SWT, wrapping around SWT code and hopefully providing a Swing like level of ease of use. JFace is a higher level wrapper around SWT, and it thus provides a cross-platform interface to SWT. [6] [7]

[edit]

Positive and negative criticisms of SWT

Template:Splitsection

There is a large amount of argument over whether SWT or Swing is the "better" GUI toolkit; however, 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." [8]

Some discussions of SWT and it's advantages and disadvantages compared to other toolkits are available at the following addresses:

[edit]

Advantages of SWT

[edit]

High performance

SWT has been designed to be a "high performance" GUI toolkit; faster, more responsive and lighter on system resource usage than Swing. [9] [10] There has been some attempted benchmarking of SWT and Swing [11] which concluded that SWT is more effecient than Swing, however the applications benchmarked in this case were not complex enough to draw any solid conclusions for all possible SWT or Swing uses.

[edit]

Native look and feel

SWT, due to it's use of native widgets features a native "look and feel" on all platforms that it supports (SWT widget screenshots from various platforms are available at http://www.eclipse.org/swt/widgets/). [12] Since SWT is simply a wrapper around native GUI code, it shouldn't require large amounts of updates when that native code is changed (at least if the API remains the same). The same cannot be said of Swing, which must be updated to mirror Operating System GUI changes (such as theme or other look and feel updates).

The above native look and feel advantages are largely due to the fact that SWT aims for "deep platform intergration", the Eclipse reference to SWTs use of native widgets. [13] [14] According to Mauro Marinillia of developer.com "whenever one needs a tight integration with the native platform, SWT can be a plus". [15] This deep integration can be useful in a number of ways, for example enabling SWT to wrap ActiveX objects on Microsoft Windows.

In partial obviation of the arguments for SWT based upon native look and feel, Swing now contains support for "pluggable look and feel" enabling "themes" emulating those of the native platform to be "plugged into" Swing applications. The extent to which this pluggable look and feel succeeds at emulating native appearance is debated.

[edit]

Clean design

It has been argued that SWT features a clean design, in part inspired by Erich Gamma of Design Patterns fame. [16] With that said, design issues for a large part may simply be issues of personal taste.

[edit]

Simplicity

SWT is a simpler toolkit compared to Swing. James Gosling has refered to Swing as a "747 cockpit" with large amounts of extraneous functionality required for corner cases. In relation, SWT is a simpler toolkit with less (possibly) extraneous functionality for the average developer. [17] This has lead some people [18] to argue that SWT lacks functionality when compared to Swing.

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)" [19]. 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" [20]

[edit]

Open Source

SWT is open source under the Eclipse Public License, an Open Source Initiative approved license – it can thus be extended at will by its users, and extensions may be redistributed freely. It should be noted that the GNU Classpath project is also beginning to provide an open source Swing replacement.

[edit]

Disadvantages of SWT

[edit]

Poor portability

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 isn't freely available on a platform as soon as Java is ported to it (as Swing is). See SWT platform support for the platforms that SWT does support, but also note that there are some allegations that SWTs support on "unusual" platforms is poorer than it is on Win32 – in particular it has been alleged that SWTs performance on platforms other than Windows is noticeably less effecient or less complete than it is on Windows [21].

James Gosling (the "father" of Java, and an outspoken critic of SWT) 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. [22] As examples of this alleged poor portability, notice that many have filed bugs with Eclipses bugzilla alleging that performance on non-Windows platforms is poor [23] and that printing with SWT, while implemented on Windows is not yet implemented on GTK [24].

[edit]

Sparse documentation

As a younger GUI toolkit than Swing, SWT isn't quite as extensively documented (in terms of number of books covering the subject) as Swing, although now there are a few books that cover SWT. [25] [26]. It should be noted that the quantity of documentation is a different matter to the more subjective quality of documentation. See SWT documentation, below.

[edit]

Simplicity

SWT is a simpler toolkit compared to Swing. James Gosling has refered to Swing as a "747 cockpit" with large amounts of extraneous functionality required for corner cases. In relation, SWT is a simpler toolkit with less (possibly) extraneous functionality for the average developer. [27] This has lead some people [28] to argue that SWT lacks functionality when compared to Swing.

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)" [29]. 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" [30]

[edit]

Deeper integration

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

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

[edit]

Poor extensibility

Due to the use of native code, SWT classes do not allow for easy inheritance, neutering extensibility. ("In addition, most of the Eclipse peers do not allow for inheritance") [33]. It should be noted that this can make creating new widgets or customizing existing widgets difficult to achieve with SWT (or at least, more difficult to achieve than if one were using Swing).

[edit]

Manual object deallocation

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 languages "free". If this is not done, memory leaks or other unintended behaviour 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." [34] The need for manual object deallocation when using SWT is largely due to SWTs 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.

[edit]

Other

Since SWT uses different libraries for different platforms, a platform specific library must be distributed to application users. In short, SWT introduces an additional dependency that the developers and client must both keep track of. This is however true of a large number of external libraries and toolkits, not just SWT. The development of SWT is driven by Eclipse. Some argue that areas of SWT that aren't heavily exercised by Eclipse aren't as well written, tested or documented as areas that are used extensively by the Eclipse project. The SWT / AWT bridge (a library enabling mixing SWT and AWT / Swing within one widget) is non-functional on Mac OS X. This is only a problem if developers plan on mixing SWT with AWT or Swing in the one widget.

[edit]

SWT platform support

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

SWT appears to be unsupported and unported on Win64 (64 bit Windows), requiring the use of a 32 bit JVM.

It should be noted that some have alleged that SWTs support on non-Windows platforms is poorer than it is on Windows – in particular, the performance of SWT on platforms other than Windows has been alleged to be ineffecient. [36] [37]

It is also 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 or on a handheld computer which may not feature the entire Java class library. [38]

[edit]

SWT applications

Applcations using SWT include:

[52] [53]

[edit]

SWT documentation

It has been alleged [54] that the external documentation for SWT is not as voluminous as the documentation for Swing, the other leading Java GUI toolkit, although the same author also claims that SWT is a "more useful" toolkit than Swing. Again, it should be noted that the quantity of documentation is a different matter to the more subjective quality of documentation. At least according to the Eclipse Foundation "before 2004, comprehensive information on SWT was not available outside the SWT source code and javadoc itself" [55], however that appears to be changing now. The definitive guide to SWT is alleged to be [Steve Northover, Mike Wilson; SWT: The Standard Widget Toolkit; Addison-Wesley] by the Eclipse Foundation themselves. [56]

Other books which cover SWT include

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

Some information on Eclipse, including SWT information within a "platform plug-in developer guide" is available at http://www.eclipse.org/documentation/main.html.

There is an SWT Javadoc API documented at eclipse.org.

[edit]

Other SWT information

There is an array of SWT information on the official Eclipse website:

There are also many SWT tutorials available online. See references and other links

There are a large quantity of Eclipse code snippets online, many of which are available from http://www.eclipse.org/swt/snippets/.

The SWT newsgroup is available at news://news.eclipse.org/eclipse.platform.swt. The newsgroup is password protected for spam protection; the password is available from http://dev.eclipse.org/newsManager/newsRequestForm.html.

[edit]

Bridging Swing and SWT

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

The Oracle Corporation has initiated JSR 198, a Java Community Process (JCP) Java Specification Request (JSR) which is attempting to define a standard API for developing IDE plugins. A standard API would be defined for all IDEs supporting this JSR, meaning that plugins working on one JSR 198 compliant IDE should theoretically work on all other JSR 198 compliant IDEs in exactly the same fashion. Unfortunately for JSR 198, the Eclipse project has thus far declined to join this effort towards a standard IDE API, and Sun has also thus far been relucatant to work towards the standard, possibly due to their existing investment in their own IDE (NetBeans). [58]

In addition, there are three seperate approaches being attempted to integrate Swing and SWT:

  1. The Eclipse project is working towards allowing Swing widget 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). Template:Citation needed
  2. 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. [59]
  3. 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. [60]
[edit]

References and other links

[edit]

Eclipse.org

[edit]

Eclipse.org bugzilla

[edit]

Eclipsepedia

Please note that while the Eclipsepedia is a Wiki, editing of the Wiki is restricted to Eclipse contributors, as noted on the Eclipsepedia main page (http://wiki.eclipse.org/index.php/Main_Page).
[edit]

Eclipse.org SWT pages

[edit]

Developer.com

[edit]

IBM developerworks

[edit]

OnEclipse

[edit]

JavaLobby

[edit]

Slashdot

[edit]

Miscellaneous

es:SWT fr:Standard Widget Toolkit ru:Standard Widget Toolkit

Retrieved from "http://www.netipedia.com/index.php/Standard_Widget_Toolkit"