【原创】SWT and Swing中文翻译稿

http://www.developer.com/java/other/article.php/10936_2179061_1
more.asp?name=80x86&id=66444
翻译一篇文章，比较初级，但是写的很好看，文章中的native，比如native platform，我都翻译成了本地的，其实我第一次翻译东西，对单词的把握对我很难，我尽量先在baidu，google上搜索这个词的中文，网上翻译成“原生”。翻译不好之处，请大家参考原文，毕竟原文才是最好的，中文的只是为了参考。我得声明，这是初稿，有很多的问题，我会改的，大家也要帮助我啊。

Swing和SWT：讲述两个Java GUI库的故事
By Mauro Marinilli

http://www.developer.com/feedback.php/http://www.developer.com/java/other/article.php/10936_2179061_1
翻译：80x86 email：liuxin8312@163.com
这篇文章里，讲述Java J2SE GUI库的内容。我们将立足于一个程序员的角度来做下面的讨论。我们假设文章的读者已经对Swing库的基础知识较为熟悉，而且想学习SWT技术（这正是我看到这个文章的原因80x86）。

我们将讨论两个Java GUI 库：
1、Swing－J2SE提到的GUI工具。
2、SWT－这个库由IBM开发，作为Eclipse平台的一部分（请注意这个地方啊 80x86）。

Eclipse是一个开源的、IBM赞助的、充分可扩展的IDE，使用java和SWT构建的。SWT起源于Eclipse的GUI库，但是它也可以脱离Eclipse使用，从而作为Sun的AWT和Swing的一个替代GUI库。

下面的部分，将介绍SWT的基础知识。我们假设读者对Swing是熟悉的。最后，我们将比较SWT和Swing。

SWT
SWT（Standard Widget Toolkit）是一个图形库，还是一个与本地（操纵系统相关的80x86）窗口系统相结合的小工具箱（尤其是与Windows，但是Linux和Solaris也同样的支持）。尽管与本地目标平台紧密的结合，SWT是一个操作系统不相关的API。SWT可以被看做是宿主（host）操作系统的本地GUI代码的一层薄薄的包装纸。在更高层次的抽象上，存在JFace，它也是Eclipse平台的一部分。这是个GUI库，使用SWT实现，用来简单化一般的GUI编程工作。JFace与特定的窗口系统不相关，在它的API和实现上都是不相关的，设计它的目的就是为了和SWT一同工作，而不隐藏它。长话短说，这里我们只讨论SWT。

简介

SWT的设计策略着重于建立一个简单的、精练的库，这个库用来制造与本地环境（及你的操作系统）紧密联系的GUI软件。SWT委托原生窗口部件（native widgets）产生普通的组件（如标签、列表、表格、等等）就像AWT的工作一样，还可以用Java模仿更复杂的组件（如，在Motif上模仿工具栏）就像Swing的策略一样。SWT已经被设计的尽可能轻量级。这意味（与其他的事物？？）它是平台相关的。无论如何，它和AWT在许多的细节上有所不同。SWT为每个平台提供了不同的Java实现，而且每个实现调用本地的（通过Java本地接口,JNI）根本的本地实现。从前的AWT与之不同的是，所有的平台相关的细节都是用C（本地的）代码书写的，而且Java实现对于所有的平台是相同的。

资源
与正常的Java编程的重要不同是，系统相关对象的管理是由SWT进行的。Swing用Java模仿了很大一部分这些对象（如窗口部件），把清除工作留给了JRE垃圾回收器。这给程序员省去了很多的复杂性，但是由于缺乏管理回导致一些意外问题，特别是跨平台开发的时候。

SWT的设计者们采取了一个不同的方式，他们迫使开发人员在程序代码中明确的释放操作系统相关的对象。SWT在头脑中被高效的设计，于是，处理特定操作系统资源就成为了一个展示高效设计的机会而不仅仅是必须这么做。SWT程序所使用的系统资源要求（代码中）释放资源来回收。这些系统资源要求调用dispose方法来明确的释放掉。

在实践中，对象的释放是一件微妙的事情，当另外一个对象尝试访问一个已经被释放的对象条目时，就会导致不可预知的结果。

一个SWT程序的基本结构

如同已经说过的，一个SWT程序依赖于本地平台的资源（被Display类封装，我们一会儿将看到）在一下两个方面，已分配的资源（如颜色、图像等等）和事件处理机制相关的资源。至于事件处理，SWT只允许一个线程来处理本地用户界面事件。

现在我们来看SWT程序的基本结构。这有助于我们理解SWT的基本体系结构。

任何的SWT程序中都使用两个基本类，Display和Shell类。Display类的实例负责管理SWT和底层操作系统直间的连接，和增强SWT的模型（比如用来增强颜色或者图像）。Shell类则描绘那些由平台相关的桌面管理器管理的窗口。典型的，一个SWT程序首先要建立一个本地资源管理器（一个Display类的实例）并且把所有需要的窗口部件都与一个以上的Shell对象相连接（赋值给80x86）。列表1显示了这个典型的机制：
列表1：显示使用Display和Shell类的代码片断
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: }

为了充分理解列表1的代码，你需要理解Display类的readAndDispatch方法。这个方法从操作系统的事件队列里读取一个事件，适当的发送它（dispatching）。如果有额外的事件要处理的话这个方法就返回true，如果调用者要等（sleep）直到另外的事件放入事件队列时就会返回false。

列表1中4－9行的循环在SWT程序中是典型的。它负责推进所有底层平台事件进入SWT程序（去处理），直到shell被释放而后程序就会退出事件循环。

基本的控制

一些基本的组件（如controls，SWT中他们叫这个名字）如下：
Button. 这个组件就是在工具栏、表格等中使用的有名的按钮组件。
ComboBox. 这个窗口部件就是有名的组合框组件。
Label. 这个窗口部件描绘一个用来显示字符串或图像的对象（不可被选择的）。
List.这个窗口部件描绘一个基本的列表组件。
ProgressBar. 它显示一个进度条。
Sash. 它是Swing中的JSplitPane的等价物。这个窗口部件能通过拉伸来改变一个GUI中两个区域的大小。
Scale. （标尺）这个组件实现一个可编辑的GUI项目，显示一个连续数值的范围。
Slider.这个组件描绘一个可编辑的对象，这个对象代表一个离散的数值范围。
Table. 这个组件描绘一个基本的表格。
Text. 这个组件描绘一个基本的文本区域。
Tree. 这个组件描绘一个基本的树窗口部件。
StyledText. 这个组件描绘一个文本区域，这个文本区域有字体风格和其他高级的属性。

SWT vs. Swing

在这篇文章中我们比较这两种技术以做出结论，那个更好，在什么时候更好？

Swing提供很多的特色，它是更加优美的，而且提供了更高层次的抽象（这在使用用户组件开发复杂GUI时是很有帮助的）。通常，SWT在开始的时候是很容易使用的，但是如果建立复杂的GUI，Swing通常是很容易使用而且更加的灵活。表格1中，显示了三个主流的GUI库所支持的主要组件。

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

 

首先，SWT看起来比Swing容易使用，因为它使开发人员免遭很多复杂的问题（比如精心制作的Swing类层次，可插入的感观look and fell，模式－视图－控制方法，等等）。无论如何，SWT的一个潜在问题是资源管理的需要。Swing（和AWT）遵循自动资源回收的Java典范，在SWT中释放本地资源需要程序员来显式明确的完成。明确的释放资源在程序调试时间里会成为一种退步（也是一种成本），至少对一般的Java开发者是这样的。这是好坏掺半的事。这对SWT程序员意味着，将要进行更多的控制（而且更复杂）而不是使用Swing时的更自动控制（而且迟钝）。

尽管SWT支持本地无关的描绘窗口组件（象Swing一样），但是默认的窗口组件是基于本地方法peers实现的（象老的AWT一样）。另外，大多数的Eclipse peers不允许继承。（显然，如果你正在写Eclipse的插件，除了使用SWT你别无选择。）

扼要的重述一下，无论何时你想与本地平台紧密的结合，SWT都会是个有利的条件（选择）。同样的，如果你想利用Java语言，但是仅想在Windows系统上使用（或者在其他几个支持的平台上使用），SWT（还有Eclipse平台）是比Swing更好的选择。但是，要谨慎注意学习使用Eclipse IDE和SWT库相关的隐藏的成本代价。而且，SWT采用的明确释放资源的机制，在一些情形下是有用的但在另外一些情形下也会是无用复杂的。如果你不想跨平台开发，而且你的目标操作系统也支持（如Windows），你就可以考虑使用SWT，尤其是你的客户使用老式的、能力有限的机器，那些机器上Swing的使用是被禁止的。对于另外所有的情形，Swing提供了稳妥的选择。

结论和参考资料

这篇文章中，我们介绍了SWT而且和Swing做了对比。我的目的是想展示这个库的初步思想和他的主要特征。我们简要的将SWT和Swing进行了对比。如下列出了一些（从许多资源中选出）可用的资源给那些有兴趣的读者们。
http://www.eclipse.org/—Eclipse项目的主页。
http://gcc.gnu.org/java/—GCJ项目主页。
http://www.java.sun.com/products/plugin/—Sun官方的关于Swing技术的网站。
http://www-106.ibm.com/developerworks/library/j-nativegui/—Vogen, Kirk的文章 "Create native, cross-platform GUI applications." 的网站

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

译者:80x86 吉林大学计算机学院的学生 liuxin8312@163.com

原文如下

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

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.

Introduction

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.

Resources

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.

• http://www.eclipse.org/—The home page of the Eclipse project.
• http://gcc.gnu.org/java/—The home page of the GCJ project.
• http://www.java.sun.com/products/plugin/—The official Sun Web site about Swing technology.
• http://www-106.ibm.com/developerworks/library/j-nativegui/—The site for Vogen, Kirk's article "Create native, cross-platform GUI applications."

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.