Swing and SWT: A Tale of Two Java GUI Libraries

转载 2004年09月22日 10:15:00

Swing and SWT: A Tale of Two Java GUI Libraries
By Mauro Marinilli

In this article, we will talk about Java J2SE graphical user interface (GUI) libraries. We will adopt a programmer's viewpoint in our discussion. We assume the reader is familiar with the basics of the Swing library and wants to explore the SWT technology.

We will discuss two Java GUI libraries:

  • Swing—The reference GUI toolkit for J2SE.
  • SWT—This library has been developed by IBM as a part of the Eclipse platform.

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.

In the following section, we will introduce the basics of SWT. We will assume the reader is familiar with Swing. Finally, we compare SWT and Swing.


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. For brevity, we will discuss only SWT here.


The design strategy of SWT was focused on building a simple, essential library that would produce GUI applications closely coupled to the native environment. SWT delegates to native widgets for common components (such as labels, lists, tables, and so on) as AWT does, while emulating in Java more sophisticated components (for example, toolbars are emulated when running on Motif) similarly to Swing's strategy.

SWT has been designed to be as inexpensive as possible. This means (among the other things) that it is native-oriented. Anyway, it differs from AWT in a number of details. SWT provides different Java implementations for each platform, and each of these implementations calls natively (through the Java Native Interface, JNI) the underlying native implementation. The old AWT is different in that all platform-dependent details are hidden in C (native) code and the Java implementation is the same for all the platforms.


An important difference from normal Java programming is the way OS-dependent objects are managed in SWT. Swing emulates a large part of such objects (such as widgets, for instance) in Java, leaving the disposal job to the JRE garbage collector. This saves a lot of complexity for the programmer but this lack of control can lead to some unexpected issues, especially with cross-platform development.

SWT designers chose a different approach, obliging the developer to explicitly dispose of OS-dependent objects in the application code. SWT has been designed with efficiency in mind, so handling explicitly OS resources becomes an occasion to promote efficient programming and not just a necessity. Resource disposal is needed to free the OS resources used by the SWT application. Such OS resources need to be explicitly de-allocated by invoking the dispose method.

In practice, disposing of objects is a delicate business and it can lead to unpredictable results whenever another object tries to access an already disposed item.

The Basic Structure of an SWT Program

As already said, an SWT program relies upon the native platform resources (wrapped by the Display class, as we will see later on) both in terms of allocated resources (such as colors, images, and so on) and as regards the event mechanism. As regards event handling, in SWT there is only one thread that is allowed to handle native user interface events.

We now see the basic structure of an SWT program. This will help us understand SWT's basic architecture.

There are two basic classes used in any SWT application, the Display and Shell classes. Instances of the Display class are responsible for managing the connections between SWT and the underlying operating system, enforcing the SWT models (for colors or images, for example). The Shell class instead represents windows managed by the platform-dependent desktop manager.

Typically, an SWT program will first create a local resources manager (an instance of the Display class) and attach all the needed widgets to one or more Shell objects. Listing 1 shows this typical mechanism.

Listing 1: A snippet of code showing the use of the Display and Shell classes.

00:     Display display = new Display();
01:     Shell shell = new Shell(display);
02:     //GUI code here
03:     shell.open();
04:     while (!shell.isDisposed()) {
05:       if (!display.readAndDispatch())
06:         display.sleep();
07:     }
08:     display.dispose();
09:   }
10: }

To fully understand the code in Listing 1, one should understand the readAndDispatch method of the Display class. Such a method reads an event from the operating system's event queue, dispatching it appropriately. It returns true if there is additional work to do, or false if the caller can sleep until another event is placed on the event queue.

The loop at lines 4-9 in Listing 1 is typical of SWT applications. It takes care of forwarding all underlying platform events to the SWT application until the shell is disposed and the program can exit the event loop.

Basic Controls

Some of the basic components (or controls, as they are called in SWT) are the following:

  • Button. This component is the well-known button component used in toolbars, forms, and so forth.
  • ComboBox. This widget is the well-known combo box component.
  • Label. This component represents a (non-selectable) object that displays a string or an image.
  • List. This widget represents a basic list component.
  • ProgressBar. It shows a progress indicator.
  • Sash. It is the Swing equivalent of a JSplitPane. It is a widget that can be dragged to resize two areas in a GUI.
  • Scale. This component implements an editable GUI item representing a range of continuous numeric values.
  • Slider. This component represents an editable object that stands for a range of discrete, numeric values.
  • Table. This component represents a basic table.
  • Text. This component represents a basic text area.
  • Tree. This component represents a basic tree widget.
  • StyledText. This component represents a text area with styled fonts and other advanced attributes.

SWT vs. Swing

We conclude this article comparing these two technologies. Which is better, and when?

Swing provides a larger set of features, it is much more elegant, and gives an higher abstraction level (that turns helpful when developing complex GUIs with custom components). In general, SWT is easier to use at first, but when it comes to building complex GUIs, Swing usually results are easier to use and more flexible. In Table 1, support for the main components is shown for the three main GUI libraries.

Table 1: Comparing visual components
Component SWT Swing AWT
Button X X X
Advanced Button X X  
Label X X X
List X X X
Progress Bar X X  
Sash X X  
Scale X X  
Slider X X  
Text Area X X X
Advanced Text Area X X  
Tree X X  
Menu X X  
Tab Folder X X  
Toolbar X X X
Spinner X X  
Spinner X X  
Table X X X
Advanced Table X X  

At first, 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). Anyway, one potential problem with SWT is in the need for resource management. Swing (and AWT) follows the Java paradigm of automatic resources disposal, while in SWT de-allocating native resources needs to be accomplished explicitly by the programmer. Explicitly de-allocating the resources could be a step back in development time (and costs) at least for the average Java developer. 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.

Although SWT supports non-natively rendered widgets (similarly to Swing), the default widget implementations are based on native peers (similarly to the old AWT). In addition, most of the Eclipse peers do not allow for inheritance. (Obviously, if you're writing Eclipse plugins, you have no choice but to use SWT.)

Recapping, whenever one needs a tight integration with the native platform, SWT can be a plus. Similarly, if one wants to take advantage of the Java language but needs to deploy only on Windows (or some of the few other supported platforms), SWT (and the Eclipse platform) is a better choice than Swing. But, be careful about the hidden costs associated with learning to use the Eclipse IDE and the SWT library. Also, the explicit de-allocation mechanism adopted in SWT could be useful in some situations and uselessly complex in others. If you don't need cross-platform development and your target OS is supported (Windows, for example), you may consider SWT, especially if your customers have old, limited machines where Swing use can be prohibitive. For all other scenarios, Swing provides the conservative choice.

Conclusions and References

In this article, we introduced SWT and compared it with Swing. My intent was to give a first idea of this library and its main characteristics. We concluded contrasting briefly SWT against Swing.

In the following are listed some (among the many) resources available for the interested reader.

About the Author

Mauro Marinilli is currently finishing his second book, on professional Java graphical user interfaces. He teaches CS courses at the University of Rome 3 in Italy while being active as a consultant and as an academic researcher in case-based reasoning, Human Computer Interaction and its applications to e-learning. You can email him at contact@marinilli.com.



MineHe原创 看了一下对Java GUI讨论的帖子,所以写了一篇文章来阐述一下各种GUI技术的优劣。 Java世界中,目前最知名的三大GUI库分别是: 1、AWT(Abstract Window ...
  • ltx06
  • ltx06
  • 2014年06月09日 20:24
  • 4772


MineHe原创看了一下对Java GUI讨论的帖子,所以写了一篇文章来阐述一下各种GUI技术的优劣。 Java世界中,目前最知名的三大GUI库分别是: 1、AWT(Abstract Window T...
  • u012886792
  • u012886792
  • 2013年11月20日 11:57
  • 986


 AWT Abstract Windows Toolkit(AWT)是最原始的 Java GUI 工具包。在任何一个 Java 运行环境中都可以使用它。 AWT 是一个非常简单的具有有限 ...
  • Gaowen_HAN
  • Gaowen_HAN
  • 2014年01月27日 18:39
  • 5811

编写Java GUI的好工具WindowBuilder Pro[包含Swt-Designer和Swing-Designer]

WindowBuilder Pro v3.0.0 这是目前最新的版本,支持Eclipse 3.0、Eclipse 3.0.1和Eclipse 3.1,此软件就是开发Swt-Designer和Swing...
  • goodstone
  • goodstone
  • 2004年12月21日 11:17
  • 5599

A tale of two viewports

终于能看到中文版的PPK大牛写的viewport故事了,感谢翻译的作者。看完之后,之前需要混乱的概念也逐渐清晰了,以下记录一些要点,以备不时翻看,详情内容请移步原文和译文网址拜读。 A tale of...
  • aiolos1111
  • aiolos1111
  • 2016年07月19日 16:19
  • 389

[新手必读] 既然有了Swing, 那为什么还要SWT?

(转载) Swing和SWT是采用不同的机制的,AWT是Swing的前身,实际上是调用本地操作系统的控件。由于在不同的操作系统下,提供的控件是不一样的,AWT采用最大公约数的办法,只提供所有操作...
  • pianistOfSoftware
  • pianistOfSoftware
  • 2016年07月15日 15:22
  • 2745


一 3大GUI开发插件的特色    Eclipse并不自带GUI的可视化开发工具,那么如果要在Eclipse进行可视化的GUI开发,就需要依靠第三方的插件。  1. Visual Editor ...
  • guoquanyou
  • guoquanyou
  • 2014年08月15日 16:27
  • 21940


笔者过去学习过Swing(也算是AWT的增强版吧), 现在开始学习一下 SWT, 还没有开始深入 JFace 和 RCP, 一步步来吧。 先学好基础的, 又不用着急做项目用。 本文讨论的内容仅限于我已...
  • jiafu1115
  • jiafu1115
  • 2012年04月05日 09:51
  • 5192

Java Swing可视化开发工具SWT Designer的安装

工具下载地址:https://developers.google.com/web-toolkit/tools/download-gwtdesigner?hl=zh-CN&csw=1 打开Eclip...
  • limenghua9112
  • limenghua9112
  • 2013年12月26日 10:54
  • 5372


  • wpc4321
  • wpc4321
  • 2008年05月31日 23:21
  • 4688
您举报文章:Swing and SWT: A Tale of Two Java GUI Libraries