To display GUI elements, the SWT implementation accesses the native GUI libraries of the operating system using Java Native Interface (JNI) in a manner that is similar to those programs written using operating system-specific application programming interfaces (APIs). Programs that call SWT are portable, but the implementation of the toolkit, despite part of it being written in Java, is unique for each platform.
Swing was the next generation GUI toolkit introduced by Sun in Java Platform, Standard Edition (J2SE) 1.2. Swing was developed to provide a richer set of GUI software components than AWT. Swing GUI elements are all-Java with no native code: instead of wrapping native GUI components, Swing draws its own components by using Java 2D to call low-level operating system drawing routines.
The roots of SWT go back to work that Object Technology International (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 problem typical of other portable graphical user interface (GUI) toolkits. IBM was developing VisualAge, an integrated development environment (IDE) 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.[2]
Design
A demo application on Linux
SWT is a wrapper around native code objects, such as GTK objects, Motif objects etc. Because of this, SWT widgets are often referred to[by whom?] 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 a compromise between the low-level performance and look and feel of AWT and the high-level ease of use of Swing.[3][4]
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."[5]
SWT is a simpler toolkit than Swing, with less (possibly) extraneous functionality for the average developer.[7] This has led some people[who?] to argue that SWT lacks functionality when compared to Swing.[8]
James Gosling, the creator of the Java language, has argued that SWT is too simple, and is a difficult toolkit to port to new platforms for the same reason that AWT once had porting problems: 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.[7]
Although SWT does not implement the popular model–view–controller (MVC) 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 cross-platform, higher-level MVC abstraction atop 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.
Look and feel
The same demo application on macOS
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 all widgets are emulations of native widgets. In some cases the difference is distinguishable. For example, the macOS tree widget features a subtle animation when a tree is expanded and default buttons have an animated pulsing glow to focus the user's attention on them. The default Swing version of these widgets does not animate.
Since SWT is simply a wrapper around native GUI code, it does not require large numbers 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, which supports the ability to change the look and feel of the running application with "pluggable looks and feels". These 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.
Programming
A simple GUI application using SWT running in a GTK environment
The following is a basic Hello World program using SWT. It shows a window (Shell) and a label.
Contrary to Swing, 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.
SWT must be ported to every new GUI library that needs supporting. Unlike Swing and AWT, SWT is not available on every Java-supported platform since SWT is not part of the Java release. There is also some evidence that the performance of SWT on platforms other than Windows is noticeably less efficient.[8] Since SWT uses a different native library for each platform, SWT programs may be exposed to platform-specific bugs.
SWT exposes programs to more low-level details than Swing. This is because SWT is technically just a layer over native library provided GUI functionality, exposing the programmer to native GUI code is 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."[10]
Since the SWT implementation is different for each platform, a platform-specific SWT library (JAR file) must be distributed with each application.
As of 2018[update], SWT supports these platforms and/or GUI libraries:[11]
As of March2018[update], SWT 4.7.3a (and 4.8M6) is officially compatible with the following operating systems (graphic library or similar if explicitly required / processors):[13]
SWT was designed to be a high performance GUI toolkit; faster, more responsive and lighter on system resource usage than Swing.[15]
There has been some attempted benchmarking of SWT and Swing, which concluded that SWT should be 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.[16] A fairly thorough set of benchmarks concluded that neither Swing nor SWT outperformed the other in the general case.[17]
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 users consider can hurt extensibility.[9] This can make customizing existing widgets more difficult to achieve with SWT than if one were using Swing.[18] Both toolkits support writing new widgets using only Java code, however in SWT extra work is needed to make the new widget work on every platform.[18]
SWT widgets, unlike almost any other Java toolkit, requires manual object deallocation, in contrast to the standard Java practice of automatic garbage collection. SWT objects must be explicitly deallocated using the dispose method, which is analogous to the C language's free.[19] 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. These objects are not tracked by the Java JVM, so it cannot track whether or not such objects are in use, and thus cannot garbage collect them at a suitable time.
In practice, the only SWT objects which a program must explicitly dispose are the subclasses of Resource, such as Image, Color, and Font objects.[citation needed]
There is some development activity to enable combining Swing and SWT. Two different approaches are being attempted:
SwingWT is a project to provide an alternative Swing implementation. It 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.[20]
SWTSwing is a project 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.[21]
Starting in 2006, there was an SWT-3.2 port to the programming language D called DWT.[22] Since then, the project supports Windows 32-bit, and 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.[23]
With JavaFX becoming part of the Java SE platform there has been interest in developing a backend for SWT that relies on JavaFX in a similar way to SWTSwing relies on Swing. A prominent project trying to achieve that was SWT on JavaFX which became part of e(fx)clipse in 2014.[24]
Uses
Applications (alphabetically sorted) using SWT include:
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 Remote Application Platform (RAP), which combines the qooxdoo Ajax library with the SWT API. Like other Java Ajax projects (such as Echo2, Vaadin and Google Web Toolkit), the usage of the SWT API allows developing applications quickly for the web in much the same way as for the desktop.
↑ Igor, Križnar (2005-05-10). "SWT Vs. Swing Performance Comparison"(PDF). cosylab.com. Archived from the original(PDF) on 2008-07-04. Retrieved 2008-05-24. It is hard to give a rule-of-thumb where SWT would outperform Swing, or vice versa. In some environments (e.g., Windows), SWT is a winner. In others (Linux, VMware hosting Windows), Swing and its redraw optimization outperform SWT significantly. Differences in performance are significant: factors of 2 and more are common, in either direction..
1 2 "Creating Your Own Widgets using SWT". eclipse.org. 2007-03-22. Retrieved 2008-12-13. Subclassing may cause bad system-level bugs, and runs the risk of leaking resources(...)Subclassing Canvas or Composite is the best way to ensure that your widget works on all SWT platforms(...)When subclassing anything other than Composite or Canvas you must override the method protected void checkSubclass() to do nothing
↑ The Java developers guide to Eclipse, 2nd ed., p359
In computing, cross-platform software is computer software that is designed to work in several computing platforms. Some cross-platform software requires a separate build for each platform, but some can be directly run on any platform without special preparation, being written in an interpreted language or compiled to portable bytecode for which the interpreters or run-time packages are common or standard components of all supported platforms.
Eclipse is an integrated development environment (IDE) used in computer programming. It contains a base workspace and an extensible plug-in system for customizing the environment. It is the second-most-popular IDE for Java development, and, until 2016, was the most popular. Eclipse is written mostly in Java and its primary use is for developing Java applications, but it may also be used to develop applications in other programming languages via plug-ins, including Ada, ABAP, C, C++, C#, Clojure, COBOL, D, Erlang, Fortran, Groovy, Haskell, JavaScript, Julia, Lasso, Lua, NATURAL, Perl, PHP, Prolog, Python, R, Ruby, Rust, Scala, and Scheme. It can also be used to develop documents with LaTeX and packages for the software Mathematica. Development environments include the Eclipse Java development tools (JDT) for Java and Scala, Eclipse CDT for C/C++, and Eclipse PDT for PHP, among others.
Swing is a GUI widget toolkit for Java. It is part of Oracle's Java Foundation Classes (JFC) – an API for providing a graphical user interface (GUI) for Java programs.
wxWidgets is a widget toolkit and tools library for creating graphical user interfaces (GUIs) for cross-platform applications. wxWidgets enables a program's GUI code to compile and run on several computer platforms with minimal or no code changes. A wide choice of compilers and other tools to use with wxWidgets facilitates development of sophisticated applications. wxWidgets supports a comprehensive range of popular operating systems and graphical libraries, both proprietary and free, and is widely deployed in prominent organizations.
Fast Light Toolkit is a cross-platform widget library for graphical user interfaces (GUIs), developed by Bill Spitzak and others. Made to accommodate 3D graphics programming, it has an interface to OpenGL, but it is also suitable for general GUI programming.
The Java Foundation Classes (JFC) are a graphical framework for building portable Java-based graphical user interfaces (GUIs). JFC consists of the Abstract Window Toolkit (AWT), Swing and Java 2D. Together, they provide a consistent user interface for Java programs, regardless of whether the underlying user interface system is Windows, macOS or Linux.
The FOX toolkit is an open-source, cross-platform widget toolkit, i.e. a library of basic elements for building a graphical user interface (GUI). FOX stands for Free Objects for X.
The event dispatching thread (EDT) is a background thread used in Java to process events from the Abstract Window Toolkit (AWT) graphical user interface event queue. It is an example of the generic concept of event-driven programming, that is popular in many other contexts than Java, for example, web browsers, or web servers.
Java AWT Native Interface (JAWT) is an interface for the Java programming language that enables rendering libraries compiled to native code to draw directly to a Java Abstract Window Toolkit (AWT) Canvas object drawing surface.
Pluggable look and feel is a mechanism used in the Java Swing widget toolkit allowing to change the look and feel of the graphical user interface at runtime.
JFace is defined by the Eclipse project as "a UI toolkit that provides helper classes for developing UI features that can be tedious to implement." The Standard Widget Toolkit (SWT) is an open source widget toolkit for Java designed to provide efficient, portable access to the user-interface facilities of the operating systems on which it is implemented.
Clutter is a discontinued GObject-based graphics library for creating hardware-accelerated user interfaces. Clutter is an OpenGL-based 'interactive canvas' library and does not contain any graphical control elements. It relies upon OpenGL (1.4+) or OpenGL ES for rendering,. It also supports media playback using GStreamer and 2D graphics rendering using Cairo.
ReAction GUI is the widget toolkit engine that is used in AmigaOS 3.2-4.1.
Model–view–presenter (MVP) is a derivation of the model–view–controller (MVC) architectural pattern, and is used mostly for building user interfaces.
GTK is a free and open-source cross-platform widget toolkit for creating graphical user interfaces (GUIs). It is licensed under the terms of the GNU Lesser General Public License, allowing both free and proprietary software to use it. It is one of the most popular toolkits for the Wayland and X11 windowing systems.
Apache Pivot is an open-source platform for building rich web applications in Java or any JVM-compatible language. It is released under the Apache License version 2.0.
The Abstract Window Toolkit (AWT) is Java's original platform-dependent windowing, graphics, and user-interface widget toolkit, preceding Swing. The AWT is part of the Java Foundation Classes (JFC) — the standard API for providing a graphical user interface (GUI) for a Java program. AWT is also the GUI toolkit for a number of Java ME profiles. For example, Connected Device Configuration profiles require Java runtimes on mobile telephones to support the Abstract Window Toolkit.
In computer science and visualization, a canvas is a container that holds various drawing elements. It takes its name from the canvas used in visual arts. It is sometimes called a scene graph because it arranges the logical representation of a user interface or graphical scene. Some implementations also define the spatial representation and allow the user to interact with the elements via a graphical user interface.
Matthew Scarpino, Stephen Holder, Stanford Ng and Laurent Mihalkovic (November 28, 2004). SWT/JFace in Action. Manning. p.496. ISBN1-932394-27-3.{{cite book}}: CS1 maint: multiple names: authors list (link)
This page is based on this Wikipedia article Text is available under the CC BY-SA 4.0 license; additional terms may apply. Images, videos and audio are available under their respective licenses.
