1、AWT和Swing由JAVA开发，符合JAVA的跨平台原则，理念上更加支持移植；
2、SWT由IBM资助的eclipse团队开发，采用较为实用的用户体验原则，界面与各个操作系统平台更加接近；
3、AWT直接使用各个平台共有的图形界面控件，导致控件类型少，功能过于简单，实用性不强。例如：由于有一种平台的按钮没有图标，所有AWT的按钮就不能有图标，在所有平台上都没有；
4、Swing使用了最少的AWT控件，尽可能多的将控件用JAVA实现，在不损失可移植性的基础上，增加了很多的功能，但在操作系统的透明控件、非矩形控件方面有些力不从心；
5、SWT使用尽可能多的操作系统控件，在此基础编程上实现附加功能，优点是界面风格与操作系统本地系统非常接近，缺点是必须为每个操作系统单独开发控件，作者认为仅有微软windows等少数几个系统上的SWT较为好用。
一个试验：
在windows平台上调整桌面的字体大小，XP上，右击桌面 - ”属性“ - ”外观" - "字体大小" - "特大" ，观察变化：
1、使用SWT的eclipse，窗口中部分字体被放大（图中红色标注）
2、使用Swing的程序，GUI完全没有变化：
相关：
Swing的线程安全
Swing程序组织 原则和技巧
Swing程序，快速建立原型
最简单的Swing程序
Swing面板和布局
AWT, SWT, Swing: Java GUI Clean Up (1)
Overview
Java GUI toolkits have always been a controversial topic. The same type of debates also happened in other languages such as Smalltalk. In fact there exist such debates on every platform-independent language. It is especially prominent in Java because Java is the most dominating language today.
So what’s the controversy? Basically, it is a dispute between people who support emulated components(or widgets, or controls) and those who support native components. There are two camps among Java developers, one of which advocates for emulated components as in Swing, and the other native components as in SWT.
History
There are many stories about around the dispute on the Internet. You should probably have already heard of them. One of them can help you to understand the whole picture. Let’s start with this one, in which Amy Fowler from Swing team is one of the protagonists.
Back in 1990s, there were three companies, which developed their products using Smalltalk. They are IBM, Digital Talk and Parc-Place. IBM and Digital Talk adopted native components, while Parc-Place believed that emulation is the way to go. At the very beginning, all things went well until IBM overtook the others. The other two then merged to form a new company named Objectshare. Then a huge battle erupted when they tried to merge their products into one. The native and emulated crowd fought the battle nearly to death. When Amy Fowler from Parc-place, who insisted on emulated components, finally won the victory, IBM had got all of their accounts, because the two companies did nothing but quarrel for an entire year. The share price of the company, went down to under 1 dollar a share and were pulled from NASDAQ because of incorrect financial reportings.
At that time, AWT had just existed. Sun had built a basic set of portable control classes that mapped to native components on the different operating systems. However AWT was very buggy. It was beyond belief this was just poor code that could be fixed. Just then, Amy was hired by Sun, and she promised to solve all of the problems by doing a lightweight solution. Convinced, Sun management to make her the head of the GUI development. Amy then hired all her old Parc-Place friends and they set about creating Swing.
In IBM, Visual Age for Java were first written in Smalltalk, which used native components. Then they started to migrate them to a Java code. All of the IBM developers are the those Smalltalk guy, and they hated Swing for its emulated nature. They reluctantly built it using Swing. At that time, it is of no doubt that Swing was ugly, slow and buggy. Therefore they created a project to migrate the Smalltalk native components over to Java. This toolkit was later called SWT, which initially means Simple Widget Toolkit and later Standard Widget Toolkit. It was a success as they released a product called Visual Age Micro Edition. The folks later found that there were bugs in Swing reading windows events, which could cause memory leaks. So they took the decision that SWT and AWT/Swing should not co-exist and then put the toolkit into Eclipse which is a tools platform derived from the early Visual Age.
The above story should have given you an overview of the history of the three, especially SWT. Now you might think, the reason IBM did to create SWT was valid and Swing should follow the way SWT has been on. Actually this opinion is very superficial. When you dwell upon to the nature of Java, you will find that it is not that simple as you expect.
Prerequisite
What is the essential feature of Java, which has influenced the decision in the toolkit design? Or what is the prerequisite of a java GUI toolkit?
The answer comes from one of Sun's promises about Java, write once, run anywhere. It is one of the java's advantages over other languages. Before Java was created, software portability was a nightmare especially to those who wanted to support multiple platforms. It is especially true in modern days when the Internet is so popular. People from different parts of the world are working on different platforms. And it is very common for a software vendor to support multiple operating systems. Java’s write-once-run-anywhere promise was obvious a relief to developers. It can greatly improve software development productivity.
However to write a portable applications, you should use those standard libraries, which provide platform-independent APIs. These standard libraries include language support, common utilities, networking, I/O and GUI toolkit, etc. So when Sun started to design the GUI toolkit, the first thing it should consider is a well-designed platform-independent API. AWT and Swing were designed carefully in such a way to avoid platform incompatibility. SWT on the contrary was initially designed without this portability in mind. It was first designed for an IDE, Visual Age for Java. And at that time, it seemed that Windows was their first priority. Therefore SWT API is more akin those of Windows. In general SWT is not as portable as Swing. Although Steve Northover, the father of SWT, argued that SWT is platform independent, you can easily find many Windows API inheritances.
Differences
GUI application is one of the major types of softwares. So Java GUI library should be standardized and integrated into the JRE platform. However different operating systems have different GUI styles and component sets. There are some components which exist on all the platforms and have similar look and feels. These common components such as button, label, textfield, checkbox, etc are also called standard components. Different gui toolkits provide different set of components. Same component from different toolkits may have different look and feel. GUI toolkit usually follows different principle when choosing component types and features to implement. When examining a gui toolkit, we generally have two different levels of concerns. One is component types, the other is component features.
Terms
First let me illustrate two mathematical concepts to you: L.C.D. and G.C.D.
L.C.D. means least common denominator. G.C.D. means greatest common denominator. Look at the figure below. There are three different sets standing for different Oses. The intersecting part is L.C.D. of the three, while the union is G.C.D. of the three.
Component Types and Features
Now let’s examine the component types and features of the three Java GUI toolkits, AWT, SWT and Swing.
AWT
AWT component set complies L.C.D. principle, which means AWT only has the common set of components which exist on all platforms. So you cannot find advanced components such as table or tree in AWT, because these components are not supported on some other platforms. As to feature set per component, AWT complies L.C.D. too. It can only support those features available from all platforms. For example, AWT buttons is not able to be attached with an icon, because on Motif platform, button is not supposed to have an icon.
Since its poor component and feature support, AWT did not attract developers much. And it is deprecated by Sun. It is only there to ensure backward compatibility and support Swing.
SWT
One of SWT’s initial goal is to provide a more rich component set than AWT. It adopts G.C.D. (greatest common denominator) principle to provide a union set of components that appear on every platform. The idea is that if a component type exists on the platform, then SWT will encapsulate it using java code and JNI call. If a component does not exist on the platform, it then emulates the component by extending and drawing a Composite. A SWT Composite is similar to AWT Canvas. By this way, SWT provides a richer component set than AWT. It is worth to point out that SWT JNI wrapper is different from AWT. Its emulation is also different from Swing.
As to component feature set, SWT is similar to AWT. They complies to L.C.D. In early SWT versions, SWT button did not support icon attachment for the same reason as AWT. But later, many of those missing features were made up using emulations. But still, there are features which cannot be implemented purely by emulation. SWT has its components completely controlled native operating system. It is hard to extend. Only features like some graphic decoration can customized by emulating. So strictly speaking, SWT component feature set can not be as rich as Swing due to its difficult to extend.
Swing
Swing is the most powerful and flexible of the three. With respect to component types, Swing complies to greatest common denominator. Because Swing controls all of the GUI system and it is very extensible and flexible, Swing can almost create any component you could imagine. The only limitation of Swing is its AWT containers. In Swing you still can not implement real transparent or irregular-shaped windows, because Swing depends on those AWT top containers including Applet, Window, Frame and Dialog etc. Except these niches, Swing has implemented almost all the standard components on every platform.
As to component feature set, Swing complies to greatest common denominator. It has most of the component features available on every platform. What's more, you can extend the existing Swing components and add more features to them.
(To be continued ...)
Posted on: 十一月 23,
Posted by: williamchen
Category: Swing
原文地址：/Swing/entry/awt_swt_swing_java_gui
