AWT, SWT, Swing: Java GUI Clean Up (1) [翻]
原文：
http://blogs.sun.com/Swing/entry/awt_swt_swing_java_gui 作者：williamchen 譯者：Matthew Chen 備注：本文是翻譯，由于部分文本網上有提供，就直接使用了。作者的初稿，不是很規范的英文，但是內容值得一讀，所以翻譯了出來，一系列共有四篇，紅字為譯者評論。
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. Java GUI 工具包一直是一個倍受爭議的話題。同樣的爭論也發生在其他編程語言如Smalltalk。實際上每個平臺無關的語言都存在著這樣的爭論。Java作為當前最受廣泛使用的編程語言而尤為突出。 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. 這場爭論在支持模擬組件(如widgets和control，在下文中也稱之為仿造組件)和支持本地組件(在下文中也稱之為原生組件)的人們之間展開，于是Java開發者形成了兩個不同的陣營，提倡使用模擬組件的Swing，和提倡使用原生組件的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. Internet上有許多圍繞這一爭論的故事。你可能已經聽說過它們中的大多數了，其中之一有助于讓你理清頭緒，讓我們就從這里開始，Amy Fowler是Swing陣營的一個倡導者。 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.
回到上個世紀90年代，曾幾何時有3家龐大的Smalltalk公司——IBM、Parc-Place和 Digitalk。在90年代初期3家公司的市場份額大致相等，生活是美好的。Parc-Place采用仿窗口部件（emulated widgets）的設計（即Swing的設計），IBM和Digitalk則采用原生窗口部件（native widgets）。后來IBM壓倒了另外兩家，因此他們打算合并成一家，假設叫做Parc-Place Digitalk。隨后當他們試圖將他們的產品融合到一個叫做Jigsaw的計劃中時爆發了一場大戰，計劃由于政治原因失敗了（開發人員實際上已經能讓它運轉起來），就因為原生和仿造兩派的死戰。Amy贏得了精神上的勝利，不
過IBM贏得了他們所有的生意，因為這兩家公司在一整年里除了吵架什么都沒做。當塵埃落定之后PPD（Parc-Place Digitalk當時已改名為Objectshare，跟Windscale改名為Sellafield的原因相同——讓人們淡忘之前發生的災難）的股票價格從60美元掉到了低于1美元1股。他們因為偽報收入被NASDAQ摘牌，從此消失。
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. 當時，AWT已經出現了。SUN當時已經建立了一套基本的可移植控件類，這些類映射到不同操作系統上的原生窗口組件（native widget），當時的AWT還滿是漏洞，遠不能稱為可靠，還需要SUN的coder們去修補。然后Amy被雇傭了，她承諾通過輕量級方案解決所有窗口組件的問題，以此說服SUN管理層讓她當了GUI開發部門的頭頭。隨后Amy雇傭了所有她過去在Parc-Place的舊朋友，讓他們來開發Swing。[不知道Amy是不是理想主義者，但我是，從我選擇Java那天起] 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. 在IBM，VisualAge for Java最初是用Smalltalk（用的是原生窗口組件）寫的，當將這些工具向Java代碼庫遷移時，他們需要一套窗口組件。IBM這邊的開發人員都是原來搞Smalltalk的那一批人，他們對管理層要求用Swing來構建WebSphere Studio工具都非常不情愿。“Swing是個可怕的充滿缺陷的怪獸“。因此開始了一個新的項目，把他們的Smalltalk原生窗口組件移植到Java上去。這個工具集后來被成為SWT，S開始是Simple的縮寫，不過后來變成了Standard的縮寫。這個項目獲得了成功，被運用在發布的 VisualAge Micro Edition產品中。他們當時發現在Swing讀事件隊列的時候用了一種可能留下內存漏洞的方式，而不得不采用他們自己的查詢 Windows事件隊列的循環，以糾正這個錯誤。這促成了他們關于SWT和 AWT/Swing不能共存的決定。他們把這個工具包放到了Eclipse中，這是一個來自于早期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. 你應該已經從上述的故事中對三者的歷史有了大概的了解，尤其是SWT。現在你也許會覺得，IBM創建SWT的理由是合理的而Swing應該沿用SWT采用的方式。這樣的觀點是片面的，當你深入了解到Java的本質之后，你會發現其實并不像你想象的那么簡單。
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? 什么才是Java本質的，影響到工具集設計的特征呢？或者說，什么才是Java GUI工具集設計的先決條件呢？ 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.
答案來自于Sun對Java的承諾之一：write once, run anywhere（一次編寫，隨處運行）。這是Java不同于其他語言的優勢所在。在Java被創建之前，軟件的跨平臺性能是開發者，特別是那些希望對多平臺提供支持的開發者的夢魘。在當今的生活中Internet的使用已經相當的普遍了，在世界不同角落的人們在不同的平臺上工作著。軟件提供商為不同的操作系統提供支持是再平凡不過的事情。Java的write-once-run-anywhere（WORA）承諾顯然減輕了開發者的負擔，極大地提高了軟件開發的生產力。
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. 然而編寫跨平臺的應用程序，你必須使用支持平臺無關性的標準庫。這些標準庫包括語言支持，公共用途，網絡，I/O和GUI工具集等。所以當Sun開始設計GUI工具集的時候，首要任務就是考慮一個設計良好的平臺無關的API。AWT和Swing都被小心地設計以保證平臺兼容性。SWT則相反，它在設計之初并不以擴展性為原則，它為一個專有的IDE Visual Age for Java而設計，Windows作為這個IDE的首選運行環境擁有很高的優先級考量。SWT API類似于WIndows，通常它并不如Swing的擴展性好，盡管Steve Northover，SWT之父，辯稱SWT是平臺無關的，你可以很容易地發現許多Windows API的痕跡。[Windows API的痕跡，并不是一個程序的問題，卻是一個跨平臺程序的問題，因為多數用linux或mac的人，對Windows上能提供的東西并不感興趣。]
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. GUI應用程序是軟件的一種主要類型，所以Java的GUI庫應該是標準化并被集成到JRE平臺中的。然而不同的操作系統有不同的GUi風格和組件集。有一些組件在所以平臺上有相似的觀感。這些共有組件如按鈕，標簽，文本域，單選框等被稱為標準組件。不同的GUI工具集提供了不同的組件集。GUI工具集總是遵循不同的原則來選擇組件類型和特征以實現。考察一個工具集，有兩個不同的要素：組件類型和組件特征。
Terms
First let me illustrate two mathematical concepts to you: LCD and . LCD means least common denominator. means greatest common denominator. Look at the figure below. There are three different sets standing for different Oses. The intersecting part is LCD of the three, while the union is 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. 現在讓我們來考察Java GUI工具集AWT，SWT和Swing的組件類型和特征
AWT
AWT component set complies LCD 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 LCD 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. AWT組件集遵循最大公約數原則，即AWT只擁有所有平臺上都存在的組件的公有集合。所以你在AWT中無法獲取如表或樹等高級組件，因為它們在某些平臺上不支持。AWT的組件特征同樣遵循這一原則。它只提高平臺上公有的特征。例如AWT按鈕不能附著圖片，因為在Motif平臺上，按鈕是不支持圖片的。 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. 由于它低劣的組件集和特征，AWT無法吸引開發者。它是Sun不推薦使用的，只是為了確保向下兼容和支持Swing。
SWT
One of SWT’s initial goal is to provide a more rich component set than AWT. It adopts (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. SWT最初的目標之一是為了提供比AWT更為豐富的組件集。它遵循最小公倍數原則以提供一個各個平臺上包含的組件的并集。思路是如果一個組件在某個平臺上包含，那么SWT就會包裝它并用java代碼和JNI來調用它。如果一個組件在某一平臺上不存在，它就會用繼承并繪制Composite的方式來模擬組件。一個SWT Composite類似于AWT的Canvas。以這種方式，SWT提供了較AWT更為豐富的組件集。值得指出的是SWT的JNI封裝不同于AWT，它的模擬也不同于Swing。
As to component feature set, SWT is similar to AWT. They complies to LCD. 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.
在組件特征方面，SWT類似于AWT。它遵循最大公約數原則。在早期的SWT版本中，SWT按鈕因為和AWT同樣的原因不支持附著圖片。在之后的版本中，許多缺失的特征采用模擬的方式補全。但仍有許多特征無法采用純粹的模擬實現。SWT將組件的控制交給本地操作系統。它難以擴展。只有例如圖形裝飾等特征可以借助模擬繪制來自定義實現。所以嚴格意義上將，SWT組件的組件集和特征因其難于擴展而不如Swing來得豐富。
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. Swing是三者中最強大和靈活的。在組件類型上，它遵循最小公約數原則。由于Swing可以控制自身GUI系統的全部并有很好的可擴展和靈活性，它幾乎可以創建所有你想象得到的組件。唯一的限制是它的AWT容器。在Swing中你還不能跨平臺地實現真正的透明化和不規則矩形窗口，因為Swing依賴于AWT頂層容器例如Applet, Window, Frame and Dialog等。除此之外，Swing幾乎實現了所有平臺上的標準組件。[都說Java7中能夠實現，也有一些跡象看來接近，期待吧] 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. 在組件特征上，Swing遵循最小公倍數原則。它擁有所有平臺上可提供的組件特征。不僅如此，你還可以繼承已有的Swing組件并添加新的特性。 AWT, SWT, Swing: Java GUI Clean Up (2)[翻] Posted on 2007-11-29 08:20 Matthew Chen 閱讀(401) 評論(0) 編輯 收藏 所屬分類: Java SE
原文：http://blogs.sun.com/Swing/entry/awt_swt_swing_java_gui1 作者：williamchen 譯者：Matthew Chen 備注：本文是四篇文章中的第二。
Implementations
The above comparison is mainly conducted in API level. Let's continue the comparison with focus on implementation details. In all the difference between Swing and SWT/AWT is that Swing is purely implemented in Java, while SWT and AWT is a mixture of Java and JNI. Of course, their target is same, to provide a cross-platform APIs. However to achieve this, SWT and AWT has to sacrifice some components and some features so that they can provide a universal APIs. 上一篇的比較主要是在API級別上的。讓我們將比較的焦點轉移到實現細節上。Swing和SWT/AWT的區別是Swing是純Java實現，而SWT和AWT是Java和JNI的混合。當然，它們的目標都是相同的，提供一個跨平臺的APIs。然而為了達到這一點，SWT和AWT不得不犧牲一些組件和特性以提供一個通用的APIs。
AWT
An AWT component is usually a component class which holds a reference with a peer interface type. This reference points to a native peer implementation. Take java.awt.Label for example, its peer interface is LabelPeer. LabelPeer is platform independent. On every platform, AWT provides different peer class which implements LabelPeer. On Windows, the peer class is WlabelPeer, which implement label functionalities by JNI calls. These JNI methods are coded in C or C++. They do the actual work, interacting with a native label. Let's look at the figure. You can see that AWT components provide a universal public API to the application by AWT component class and AWT peers. A component class and its peer interface are identical across platform. Those underlying peer classes and JNI codes are different. 一個AWT組件通常是一個包含了對等體接口類型引用的組件類。這個引用指向本地對等體實現。舉java.awt.Label為例，它的對等體接口是LabelPeer。LabelPeer是平臺無關的。在不同平臺上，AWT提供不同的對等體類來實現LabelPeer。在Windows上，對等體類是WlabelPeer，它調用JNI來實現label的功能。這些JNI方法用C或C++編寫。它們關聯一個本地的label，真正的行為都在這里發生。作為整體，AWT組件由AWT組件類和AWT對等體提供了一個全局公用的API給應用程序使用。一個組件類和它的對等體接口是平臺無關的。底層的對等體類和JNI代碼是平臺相關的。
SWT
SWT implementation also utilize JNI methodology. But the detail is different from that of AWT. SWT evangelists often became furious when they heard people describing SWT as another AWT. Steve Northover, the father of SWT, once complained about this. SWT也使用JNI的方法論來實現。但細節不同于AWT。SWT的擁護者聽到人們拿SWT和AWT相提并論可是會很生氣的，Steve Northover，SWT之父，就曾為此抱怨過。 Yes, they are different. Let's delve into SWT code. In SWT, the only identical part on every platform is the component interface. That is class and method definition signature. All the underlying codes are different from platform to platform. SWT provides an OS class for every platform. This class encapsulates many native APIs by JNI methods. And then SWT component class glues these JNI method together to provide a meaning functionality. 沒錯，它們是不同的。讓我們深究SWT的代碼。在SWT中，各個平臺上唯一相同的部分是組件的接口，是類和方法的定義簽名。所有的底層代碼都是平臺差異的。SWT為每個平臺提供了OS類。這個類用JNI封裝了許多本地APIs。SWT組件類通過把這些JNI方法黏合在一起提供一個有意義的功能。
For example, on Windows, text field selection can be conducted by only one system call. This system call is implemented in the Windows OS class as an native method. So there is only one JNI call in the setSelection method of Text on Windows. 例如，在Windows上，文本域的選擇是由一個系統調用處理的。這個系統調用在Windows的OS類中作為一個本地方法實現。所以在Windows平臺的Text的setSelection方法中只用到了一個JNI調用。 However, on motif platform, text selection involves two native calls. Again SWT implements these two calls in the motif OS class. So the component class on motif needs to call these two calls to achieve text selection. 然而，在motif上，文本域的選擇包含兩個本地調用。SWT就在motif的OS類中實現了兩個調用。所以在motif上組件類需要作兩次調用來實現文本的選擇。
By now, you can see the major difference between SWT and AWT is that they use different peer code to wipe out the differences. SWT uses java code, or java peer to glue system calls implemented by JNI. However, AWT put these code in native peers, which complicates the situation. I think SWT's method is more clever. 現在你應該能看出SWT和AWT的最大不同了，它們使用了不同的對等體編程方式來消除平臺差異。SWT用java代碼或有JNI實現的java對等體來黏合系統調用。而AWT把代碼包含在對等體中，使情況復雜化了，我個人覺得SWT的方法更加明智。[是否我翻譯有問題，因為我并不覺得是這樣更明智，SWT的無則模擬是不必要的，這是使用者才去做的事，SWT作為提供者應該無則C++實現，當然實現的是最核心的高度復用的又或者需要極大性能支持的，畢竟帶了動態鏈接庫，索性多放點東西。]
Swing
When it comes to Swing, everything becomes clear and straight forward. Except the top containers, Swing implementation depends on nothing of individual platform. It has all the controls and resources. What Swing needs is event inputs to drive the system, and graphics, fonts and colors which are inherited from the top AWT containers. Ordinary Swing components can be seen as a logical area on AWT containers. They do not have a peer registered. All swing components added to a same top container share its AWT peer to acquire system resources, such as font, graphics etc. Swing has its own component data structure stored in JVM space. It manages drawing process, event dispatching and component layout totally by itself.
到了Swing這里，一切就變得清晰和直接了。除了頂層容器，Swing的實現不依賴于具體平臺。它掌管了所有的控制和資源。Swing所需要的是事件輸入來驅動系統，以及承接自頂層AWT容器的圖形處理，字體和顏色。普通的Swing組
件可以看作是AWT容器的一塊邏輯區域。它們并沒有注冊對等體。所有添加到同一頂層容器的Swing組件共享它的AWT對等體以獲取系統資源，如字體，圖形處理等。Swing將組件自己的數據結構存儲在JVM的空間中。它完全由自己管理畫圖處理，事件分發和組件布局。
Resource Management
Because both AWT and SWT holds reference to native components, they must release them in a correct manner to avoid memory leaks and JVM crashes. AWT takes most of the resource management task to the system, relieving developers from tedious resource management. However this complicates the AWT implementation. Once it is implemented, developers has less opportunities to make errors and crash their applications. 由于AWT和SWT都持有對本地組件的引用，它們必須以正確的方式釋放這些引用以避免內存泄露和JVM崩潰。AWT將絕大多數資源管理任務交給系統，將開發者從單調乏味的資源管理中解救出來。然而這使得AWT的實現復雜化了。一旦它實現了，開發者很少有機會犯錯誤并使他們的程序崩潰。 SWT follows another way. In essence, SWT let the developers to manage those resources by themselves. There's a famous rule there. That is those who create the component should release it as well. Thus developers have to explicitly and carefully call the dispose method on every component or resource he has created. This greatly simplifies the SWT implementation model. But it puts the developers at the risk that they might easily crash their applications due to incorrect coding. SWT用的是另一種方法。大體上，SWT讓開發者自己來管理資源。它的一條著名的規則是：誰創建，誰釋放。因此開發者必須謹慎地顯式調用dispose方法釋放每一個由他創建的組件和資源。這簡化了SWT的實現模型，但把開發者擺在了因錯誤編碼而易于造成程序崩潰這一風險之上。
Emulation difference模擬方式的區別
Both Swing and SWT uses emulation in their implementation. SWT emulate those components which are missing from one platform. The difference is that SWT's emulation is much more like those of AWT Canvas. SWT has a Composite class which has a counterpart peer in the operating system. It gets all the resources it needs such as graphics object, font or color from its own peer. It gets all the events directly from the operating systems process it. However, swing component does not have a counterpart peer. It is only
logical area of the top container. The resources it acquires from itself are in fact borrowed from those top containers' peer. As to event, swing event is not the event generated from the underlying system. It is in fact a pseudo event which is generated when the top container processes AWT event. We'll detail it later in the event parts. Swing和SWT在它們的實現上都使用了模擬。SWT只模擬平臺上缺失的組件。區別是SWT的模擬更像是AWT的Canvas實現的模擬。SWT的Composite類有它自己在操作系統中相應的對等體。它從自己的對等體中獲得所有它所需要的資源如圖形處理的對象，字體和顏色等。它直接從操作系統獲取所有的事件并進行處理。然而，Swing組件在操作系統中沒有相應的對等體。它只是一塊頂層容器中的邏輯區域，實際上它從頂層容器的對等體中借用資源。Swing的事件并不是底層系統產生的事件。它們實際是由頂層容器處理AWT事件所產生的偽事件。我們會在稍后的事件部分中詳細介紹它。
Graphical Layer Architecture圖形層結構
The other difference is that swing components have its own separate z-order system from AWT components. As I mentioned above, swing components share a same peer with the top AWT container. Therefore, swing components have same z-order with the top container. SWT and AWT components each have a different z-order from the top container. So if AWT components and Swing components are mixed together, Swing components will probably be hidden by AWT components, because z-order values of AWT components are higher than the top container, while Swing components have the same z-order value with the top container. When operating system begin to update the UI, top container and swing components are always painted earlier than those of AWT. When they finished painting, AWT components will wipe out what swing has painted. So it is not encouraged to mix swing and AWT components together. If there are floating swing components such as menu, AWT component probably can hide menus. 另一個不同之處是Swing組件的z-order系統是來自于AWT組件的。如上所述，Swing組件與頂層AWT容器共享一個對等體。因此，Swing組件也和頂層容器有相同的z-order。SWT和AWT組件都有不同于頂層容器的z-order，通常是高于頂層容器。故而如果AWT組件和Swing組件混合在一起的話，Swing組件將可能被AWT組件遮住。當操作系統開始更新UI的時候，頂層容器和Swing組件總是先于AWT組件繪制。當它們完成繪制，AWT組件會覆蓋Swing可能繪制過的地方。因此不提倡Swing和AWT組件的混用。如果有一個浮動的Swing組件如菜單，AWT組件很可能遮蓋菜單。
Layout Manager布局管理器
Not all of the elements of the three are different. Layout manager is an exception. What is layout manager? When developing a gui application, developers need to re-position or resize components when the container is resized. In traditional language, this is usually achieved by listening to resizing events. The code snippets usually scattered around and mess up the code. Java introduces the idea of wrapping layout codes together and name it Layout Manager. When a layout manager object is set to the container, it is automatically connected to resizing events. When resizing happens, layout method of the manger is called to re-position or reshape its children components. 并不是三者中的所有部分都是不同的。布局管理器是一個例外。開發GUI應用程序，當容器改變大小的時候，組件需要重定位或改變大小。在傳統的編程語言中，這依靠監聽大小改變的事件來實現。相應的片段散落在源代碼的各個角落降低了程序的可讀性。Java引入了將布局代碼封裝的思路，稱之為布局管理器。當布局管理器對象被設置到一個容器中，它自動處理大小改變的事件。當大小改變時，管理器的布局方法被調用以重定位子組件或調整它們的形狀。 AWT, SWT and Swing agree on this infrastructure. However every one has its own specific layout managers. Because AWT and Swing share a common parent class java.awt.Component, therefore AWT and Swing layout manger can work interchangeably. AWT，SWT和Swing都以這樣的方式來組織，而都有它們各種獨特的布局管理器。由于AWT和Swing擁有一個共同的超類java.awt.Component，它們的布局管理器可以交替地使用。 AWT, SWT, Swing: Java GUI Clean Up (3) [翻] Posted on 2007-11-29 08:21 Matthew Chen 閱讀(412) 評論(0) 編輯 收藏 所屬分類: Java SE
原文：http://blogs.sun.com/Swing/entry/awt_swt_swing_java_gui2 作者：williamchen 譯者：Matthew Chen 備注：內容有一些也是我以前不知道的，我也不得不說兩句，紅字為評論。
Look And Feel觀感
Native toolkits including SWT and AWT do not support Look And Feel mechanism. They bind their components to operating systems, which have both pros and cons. One of the cons is that they cannot support pluggable Look And Feel. Handling the drawing process to operating system deprives of their ability to customize component look and feel. This prevent them from providing Look And Feel mechanism. Look And Feel mechanism is becoming more and more indispensable in GUI toolkit. 包括SWT和AWT在內的本地工具集并不支持Look And Feel機制。它們將組件捆綁在操作系統上，有其優勢和劣勢。其中的一個劣勢是它們不支持可插拔的Look And Feel。將繪制處理交由操作系統完成剝奪了它們實現自定義組件Look And Feel的能力，也就使得它們無法提供這種機制。Look And Feel機制越來越成為GUI工具集中不可缺少的一部分。
Swing has wonderful Look And Feel support. You can even change Swing application's look and feel dynamically. This is an insurmountable task for AWT and SWT, since they handle their control entirely to operating system. I've heard many people complains about Sun on Swing design. They think why Swing can not be built on SWT like AWT. In fact, Look And Feel mechanism is one of reason why Swing should go in that direction. If Swing follows the way that wrapping existing components and emulating
non-existing components, it cannot provide Look And Feel mechanism. Providing pluggable Look and Feel mechanism is an insurmountable task to native strategy. Swing擁有很好的Look And Feel支持。你甚至可以動態地改變Swing應用程序的Look And Feel，鑒于AWT和SWT將組件控制完全交給操作系統處理，這是它們所無法超越的任務。我曾經聽很多人抱怨過Sun在Swing上的設計。他們覺得Swing為什么不像SWT那樣沿用AWT的思路呢？事實上，Look And Feel機制正是Swing走到這個方向上的原因之一。如果Swing遵循的是包裝已有的組件并模擬不存在的組件的路線，那它就無法提供Look And Feel機制。因為提供Look And Feel機制是本地策略所無法完成的任務。
Graphics and Fonts圖形和字體
Since Swing is an emulated system, its graphics tools is much more powerful than those of AWT and SWT. Swing bases its whole system on two fundamental components, one is Java 2D and the other is AWT. Java 2D is a powerful library in Java. It provides rich features of advanced image processing, color management, graphical drawing and filling, coordination system transmission and font manipulations. AWT and SWT only provides limited access to these features. Compared to Java 2D, they are comparably primitive and inferior. Swing作為一個仿生系統，它的圖形工具集較之AWT和SWT強大許多。Swing基于其自身系統中的兩個基礎組件群：Java 2D和AWT。Java 2D在Java中是強大的類庫，它為高級圖像處理，顏色管理，圖形繪制和填充，坐標系變換和字體生成提供豐富的特性。相較之下，AWT和AWT僅對這些特性提供有限訪問，它們是相對原始和低級的。
JavaBeans Specification Conformity JavaBeans規范一致性
Swing and AWT was designed with JavaBeans specification in mind. So their component classes conform to JavaBeans specification. However SWT does not quite conforms to this specification. For example, there's no empty-argument constructor in every component classes. Every component in SWT must has at least a single parameter constructor. This parameter is the parent of the components. That means whenever a component is created, it must be immediately added to a component tree. A component cannot exist without registered native peer. By this way, SWT wants the components created by programmer can be automatically released when dispose methods of display is called. Swing和AWT在設計之初就秉承了JavaBeans規范，它們的組件類與JavaBeans規范一致。然而SWT并沒有很好的遵循這一規范。例如，在SWT的組件類中沒有無參的構造器。每個組件都必須至少擁有一個單參數的構造器。這個參數就是父組件的引用。這意味著無論何時組件被創建，它都直接被添加到一棵組件樹中。一個組件無法脫離于已注冊的本地對等體而存在。這樣，SWT就能讓由編程者創建的組件在display的dispose方法被調用的時候自動被釋放。
More on Resource Management更多在資源管理方面的內容
SWT's strategy of component constructor can eliminate some possibility of memory leaks. AWT has the similar question about resource management. But it resolve the issues using a different way. When an AWT component is created, the counterpart peer will not immediately be added. When it is added to a component tree, but the tree is not visible yet, the peer will be still not created. Only when top container is set visible, will these peers be created. The method creating the peer generally is located in addNotify method. They generally call their parent's addNotify recursively until all of the peers on the component tree are created. When top container is dismissed by calling dispose method, a reverse method removeNotify will be called recursively to release these peers. By this way, AWT manage its resource without any interference from the developers.
SWT的組件構造器策略可以排除某些內存泄露的可能性。AWT在資源管理方面也有類似的問題。但它采用了不同的方式解決。當AWT組件被創建的時候，相應的對等體并不會立即被創建。即便它被添加到一棵組件樹，而如果這棵樹還不
可見，那么對等體仍不會被創建。只有當頂層容器被設為可見，這些對等體才會被創建。創建對等體的方法通常在addNotify中，它們通常遞歸地調用父組件的addNotify直到整棵組件樹上的對等體都被創建了。當頂層容器由dispose方法銷毀的時候，一個對應的方法removeNotify將會被遞歸地調用以釋放這些對等體。這樣，AWT在不由開發者介入的情況下管理了它的資源。
Event System事件系統
An event is the message sent to a GUI system, either from the outside or from the system itself, which requires certain action to be taken. These events include I/O interrupts from computer devices such as mouse or keyboard or network ports, and logical events triggered by GUI system, such as ActionEvent posted by a button. 一個事件要求特定的動作被執行，它被作為消息由外界或系統自身發送給GUI系統。這些事件包括來自計算機設備如鼠標鍵盤和網絡端口的I/O中斷，以及GUI系統的邏輯事件觸發，比如一個按鈕的ActionEvent事件。
Single-Threaded vs Multiple-Threaded 單線程 vs 多線程
Dispatching events can follow two different models. One is called single-threaded dispatching model and the other multiple-threaded dispatching model. 事件分發遵循兩種不同的模型。單線程分發模型和多線程分發模型。
In single-threaded dispatching model, an event is pumped from the queue and processed in the same thread immediately. After the event being processed, next pending event in the queue is pumped again and continues the next round of cycle. In multiple-threaded dispatching model, the thread fetching the
events from the queue launches another thread called task thread, and hand the event over to it for processing. The thread responsible for fetching the event does not wait for the end of the processing thread. It simply goes on to fetch next pending event and dispatch it. 在單線程分發模型中，一個事件從隊列中抽出并在同一個線程中被立即處理。事件處理后，隊緊跟著的下一個事件再被抽出并繼續下一輪的循環。在多線程分發模型中，從隊列中獲取事件的線程啟動另一個被稱作任務線程的線程，并把事件交給它處理。而獲取事件的線程并不等待處理線程的結束。它簡單的獲取下一個線程并分發它。 Event processing usually involves changing application data. While these data are often the source data that components display. Multiple-threaded dispatching can easily raise synchronization issues. It generates multiple event processing threads, which might interfere with each other. In a stable GUI system, component should be able to keep the view synchronized with the model. Because of the synchronization issue, multiple-threaded model requires developers to be more experienced in concurrent programing. For ordinary programmers, it is very easy to make synchronization errors. Therefore many GUI system don't use this model. 事件處理通常涉及應用程序的數據變化。而且這些數據經常是組件需要顯示的。多線程分發很容易產生同步問題，它產生多個可能互相干擾的事件處理線程。在一個穩定的GUI系統中，組件應該能夠保持視圖與模型間的同步。由于同步問題的出現，多線程模型要求開發者擁有更多并發編程的經驗。而對于普通編程人員，造成同步錯誤是很容易的。因此許多GUI系統并不使用這一模型。 Single-threaded model provide natural synchronizations by enforcing sequential event processing. AWT, SWT and Swing all use this model to dispatch events. But single-threaded model also has its own issues. One of them is thread engrossment. Since all events are dispatched by a single thread, if one event processing last too long, it will hold back pending events from being processed. If there are PAINT event holding back, then the screen will appear to be unresponsive. This usually make user feel that the software is slow. There are many such slow applications that are programmed by inexperienced developers. What they did is most probably cramming a listener method with time-consuming tasks. Swing is especially prominent, since it is widely used. This has brought swing a bad reputation of slow and ugly. In fact, swing application can be very responsive if you knows to thread. 單線程模型通過強制事件序列化地被處理提供了實際上的同步。AWT，SWT和Swing 都采用了這一模型來分發事件。但單線程模型也會有它自己的問題。其中之一就是線程專注。既然所有的事件都在一個線程中被分發，如果其中的一個事件的處理費時過久，將會拖延下一個事件的抽取和執行。如果有一個PAINT事件被延后，那么在屏幕上就會呈現為無法響應。這經常使用戶感覺到軟件很慢。許多這樣的低效程序是由于開發者的經驗不足造成的。他們的做法是將耗時任務填充到監聽器方法中。由于這種錯誤的編程方式在Swing中大量被使用而尤為突出，這也是它慢而丑陋的壞名聲的由來之一。實際上，如果你懂得使用線程，Swing應用程序可以表現出很高的響應度。[沒錯，三者在gui上都是典型的單線程事件分發模式，如果你了解操作系統和編程語言的實現細節，你就不會對此表現的詫異，因為單核中，多線程和多進程本質上也是單任務處理基礎上的抽象。]
Thread Safety線程安全
The solution to the above issue is launching a separate worker thread to handle long-time processing, thus releasing the event dispatching thread to continue. Just like what multiple-threaded model does. But that also invites the synchronization issues that happen in multiple-threaded model. Many GUI toolkits often setup some innate mechanism to avoid this, for example, by a complex lock on a component tree. Developers don't have to worry about how to program to be safe. This kind of toolkit is called thread-safe. AWT is one of them.
上述問題的解決方案是啟動一個單獨的工作者線程來完成耗時處理，這樣就能把事件分發線程釋放處理以繼續運作。如果多線程模型中所做的那樣，然而這同樣會引入在多線程模型中出現的同步問題。許多GUI工具集都有自己先天性的機制來解決這一問題，例如，在組件樹上的組合鎖。開發者不需要為如何安全編程而操心。這樣的工具集被成為線程安全的。AWT就是其中之一。 However, it is often too complex to build such GUI system and usually it creates a lot overhead because of unnecessary synchronization. Therefore, Swing and SWT were designed to be thread unsafe. That means developers have to program carefully when they want to do multi-threading task. There is a little difference between SWT and Swing about runtime behavior towards thread safety. SWT always checks if the action modifying component takes place in the event dispatching thread. By this way, developers can find out the probable synchronization issues. Swing does not have. This is a shortage of Swing, which I think should not be so hard to implement. 然而，由于不必要的同步使得建立這樣的GUI系統過于負責并造成了額外的開銷。因此，Swing和SWT被設計為非線程安全的，這意味著開發者必須謹慎地實現他們的多線程任務。SWT和Swing在運行時線程安全行為上有一個小小的區別。SWT總是檢查改變組件的操作是否在事件分發線程上執行。這樣，開發者就能夠發現同步問題。而Swing不這樣，這是Swing的一個不知之初，這其實并不難實現。[Swing似乎有相應的checkLock這樣的方法，檢查是否在事件分發線程上執行應該已經由Swing實現了，你不必顯示調用它，因為你調用的每一個組件操作方法都首先要執行一遍它]
Event Dispatching Thread事件分發線程
AWT reads the primitive event from the operating systems and process them in java codes. AWT event dispatching thread is named as AWT-{OS}-Thread. This thread is launched implicitly by AWT system. When an AWT application launches, this thread starts in background, pumping and draining events from the operating systems. When logical events such button action is fired, it is passed over to action listeners registered on button. Developers can also listen to primitive events such as mouse, keyboard or paint event to write customized AWT components. This is generally done by extending AWT Canvas component. This component enables all of the available event happened on them, and by overriding the event processing method, you can implement a custom component. AWT讀取操作系統中的基本事件并在java代碼中處理它們。AWT事件分發線程被命名為 AWT-{OS}-Thread。這個線程由AWT系統隱式啟動。當AWT應用程序啟動時，這個線程在背后啟動，在操作系統上抽取和移除事件。當諸如按鈕動作這樣的邏輯事件被觸發時，它傳遞給注冊在按鈕上的操作監聽器。開發者也能為AWT組件編寫鼠標，鍵盤和繪制事件的事件監聽器。這通常通過擴展AWT Canvas組件來完成。這一組件支持了所有已提供的事件，而且你可以通過重寫事件處理方法，實現一個自定義的組件。 However, in Swing, this is a different thread. Swing takes AWT events as the input of its event system. It gets AWT events and after some initial processing, generate a swing counterpart event and put it into its own event queue. Swing has own dispatching thread, usually named EventQueue-0. This thread pump swing events from the event queue, just as AWT does from the operating system. Then it dispatches this event to the target components. Usually an event is first post to the top container components. This event is then processed by the top container's dispatch methods. Then it may re-dispatching or re-targeting this event to a swing component, which in turn continues the processing by its listeners. 然而，在Swing中，這是一個不同的線程。Swing把AWT事件作為自身事件系統的一個輸入。它獲取AWT事件并做一些初始化處理，產生一個對應的Swing事件并把它放到自己的事件隊列上。Swing也有自己的事件分發線程，通常命名為EventQueue-0。這個線程從事件隊列中抽取Swing事件，就如同AWT從操作系統中抽取那樣。然后它把事件分發給目標組件。通常事件首先被分發給組件的頂層容器，然后由頂層容器的dispatch方法處理，它可能被再分發或重定向到一個Swing組件，在那里繼續由自己的監聽器進行處理。
For example, when a mouse moves over a Jbutton on a Jframe, an AWT event targeting Jframe is fired to the AWT-thread. The AWT-thread checks to see if it needs further processing. Then it wraps the event into a Swing MouseEvent object and enqueue it into the EventQueue. Upon receiving the MouseEvent, EventQueue-0 pumps this event out and dispatch it to Jframe by calling its.dispatching method. This method then translate MouseEvent and figure out the target Swing component. Here, the component is Jbutton. After that, it created a new MouseEvent with the new coordinations and event source re-target to the Jbutton. After that, it calls the jbutton.dispatch to continue dispatching. Jbutton.dispatch filters these event to a specific method and finally hit the point where it is dispatched to specific mouse listener. 例如，當一個鼠標移過一個JButton或JFrame時，一個指向JFrame的AWT事件在AWT線程上觸發。AWT線程檢查它是否需要作更多的處理，然后把它包裝成一個Swing的MouseEvent對象并把它添加到EventQueue隊列中。當獲得MouseEvent事件后，EventQueue-0抽取這個事件并判斷出目標Swing組件。這里，這個組件是JButton。然后它產生了一個包含相對坐標位置和事件源的新的MouseEvent重定向到這個JButton上，然后調用這個JButton的dispatch以繼續分發。JButton的dispatch過濾事件給特定的方法最終實現由鼠標監聽器在該點上的分發的點擊。 SWT is more akin to AWT. The only difference is that it requires the developers to explicitly write the event looping codes. However, the underneath implementation is different from that of AWT. Look at the code that SWT read and dispatching events, it reminds you MFC code style. SWT更類似于AWT。唯一的區別是它要求開發者顯式地書寫事件循環代碼。然而底層的實現細節是不同于AWT的。看看SWT的讀取和分發事件代碼，它會讓你想起MFC的代碼風格。
Event Listener事件監聽器
AWT, SWT and Swing have similar event listener models. They all use observer pattern, in which, components and listeners are connected by adding listeners to components. This model forms a object-net model as shown in the following figure. When an event is fired and transmitted to the component by dispatching, the component call its listeners to process this event. A listener can also further dispatching this event after processing, or it can event generate a new event and broadcast it to other nodes of the net. Basically there are two different way of broadcasting events. One is synchronously calling other listeners. The other is asynchronously posting this event to the queue, where it can get dispatched during next round of event dispatching. AWT，SWT和Swing都有相似的事件監聽器模型。它們都使用觀察者模式，組件和監聽器的連接方式是把監聽器添加到組件上,這組成了一個對象網絡的模型。當事件被觸發并分發給組件，組件調用它的監聽器以處理事件。一個監聽器也可以繼續分發事件給后續的處理，或產生一個新的事件并把它廣播到網絡中的其他節點上。基本上有兩種不同的廣播事件方式。一種是同步調用監聽器。另一種是異步地將事件發送回隊列，它將在新一輪的事件分發中被分發出去。 Besides post method, Swing has some other way of dispatching asynchronous event. One of them is invokeLater from SwingUtilities or EventQueue. This method can wrap a Runnable object into a event and post it into the event queue. This ensures the run method of Runnable can be executed on the event dispatching thread, enabling thread-safety operation. In fact, Swing Timer and SwingWorker is implemented based on this mechanism. SWT also has this counterpart utilities which can asynchronously post events. Its invokeLater counterpart is display.asyncExec which takes a Runnable object as parameter. 除了直接發送給隊列的方式，Swing還有一些其他的分發異步事件的方法。其中之一是調用SwingUtilities 或EventQueue 的invokeLater，這一方法包裝一個Runnable對象到事件中并把它發送給事件隊列。這確保了Runnable的run方法能在事件分發線程上執行，保證了線程安全。實際上，Swing的Timer好SwingWorker基于這一機制實現。SWT也有相應的發送異步事件的方式。它的invokeLater的對應方法是display.asyncExec，它以一個Runnable對象作為參數。
AWT, SWT, Swing: Java GUI Clean Up (4)[翻] Posted on 2007-11-29 08:22 Matthew Chen 閱讀(482) 評論(3) 編輯 收藏 所屬分類: Java SE
原文：http://blogs.sun.com/Swing/entry/awt_swt_swing_java_gui3 作者：williamchen 譯者：Matthew Chen 備注：翻譯好累，但是第4篇是最有料的，我又不得不用紅字寫一些看法了。
Pros & Cons
To conclude the article, I'll give a list of pros & cons for each of them from a technical perspective. 我從一個技術層面給出了他們優劣勢上的一個清單，以結束本文。
AWT
AWT is a deprecated toolkit by Sun. However, it does has advantage. In many areas other than desktop environment such as mobile or embedded device, AWT has many advantages. AWT是Sun不推薦使用的工具集。然而它在許多非桌面環境如移動或嵌入式設備中有著自己的優勢。[SWT因相同的理由在mobile環境中也具有優勢，那Android呢。Java是世界上用得最廣泛的編程語言，然而分裂和變異是生命體進化的必然，java guys，你準備好面對即將到來的一切了嗎？] Less memory. Therefore it is suitable for developing GUI application which runs in an limited environment, for example, mobile phone and so on. 更少的內存。它對運行在有限環境中的GUI程序的開發，是合適的。
1. Less startup time. Because AWT components are native components which are implemented by the operating system, most of the binary codes can be loaded in advanced, for example, when operating system starts. This can help to reduce AWT application startup time.
2. More responsive, Because native components are rendered by operating systems.
3. Standard GUI toolkit supported by JRE since java 1.x time. You don't have to install them separately. You don't have to worry about platform differences.
4. Mature and stable. Seldom will it crash you applications and it just works.
1. 更少的啟動事件。由于AWT組件是本地由操作系統實現的。絕大多數的二進制代碼已經在如系統啟動的時候被預裝載了，這降低了它的啟動事件。 2. 更好的響應。由于本地組件由操作系統渲染。 3. 從java 1.x時代就為JRE支持的標準GUI工具集，你不用單獨安裝它，你不用擔心平臺差異的問題。 4. 成熟穩定的。它能夠正常工作并很少使你的程序崩潰。 However, everything has its own Achilles heel. Let's enumerate them: 然而，事物都有它們不好的一面。讓我們來例數它吧。
1. Less component types. Table and tree are very important components missing. while table and tree are very commonly used components in desktop applications.
2. Lacking rich component feature. Its buttons cannot have icon attached. This is clearly due to the fact, it is design according to principle.
3. No Look And Feel support. AWT is designed to use native components. Therefore, it depends on the system to provide Look And Feel support. If there are no such support on the target platform, there's no way for AWT to change its look and feel.
4. Not extensible. AWT components are native components. The JVM instance of AWT classes are in fact only references to the native components. The only extension point of AWT is its Canvas component, where you can create a custom component from scratch. However there's no way to extends and reuse an existing AWT component.
1. 更少的組件類型。表和樹這些重要的組件缺失了。它們是桌面應用程序中普遍使用的。 2. 缺乏豐富的組件特征。按鈕不支持圖片附著。這很明顯是它遵循的設計原則造成的。 3. 不支持Look And Feel。AWT被設計為使用本地組件。因此，它依賴系統來提供Look And Feel支持。如果目標系統并不支持這一特性，那么AWT將無法改變它的Look And Feel。 4. 無擴展性。AWT的組件是本地組件。JVM中的AWT類實例實際只是包含本地組件的引用。唯一的擴展點是AWT的Canvas組件，你可以從零開始創建自定義組件。然而無法繼承和重用一個已有的AWT組件。[SWT同樣，extends在這里的使用確實不如Swing可以做到的事情多，但別忘了原生只是人們加給SWT的一個名字而已，它的姓是IBM]
SWT
SWT has the following advantages: SWT有如下優勢：
1. Rich component types. SWT provide a wide variety of components, from primitive components such as Buttons and Labels to Tables and Trees.
2. Relative rich component feature. Although SWT is also designed following LCD principle, it has been re-engineered to support more component features by emulations. So compared to AWT, it has relative more component features.
3. Better response time. Due to the same reason as AWT, SWT components are wrapped native components, which are rendered by the operating system. Operating system can usually optimize the rendering process. It often store the GUI binaries as shared library, which reduces memory footprint, therefore improve the response performance.
4. Less memory consumption. It is easy to understand this point, since operating system can take care of the native components for applications.
1. 豐富的組件類型。SWT提供了種類繁多的組件，從基礎組件如按鈕和標簽到高級的表格和樹。 2. 相對的豐富組件特性。盡管SWT也遵循最大公倍數原則，它可以采用模擬的方式重新設計了對更多組件特性的支持。所以同AWT相比，它有著相對豐富的組件特性。
3. 更快的響應時間。基于和AWT同樣的原因，SWT組件包裝了本地組件，由操作系統實現渲染。操作系統通常對渲染處理做了優化，保存GUI二進制代碼為標準庫，減少了內存的使用，提高了響應性能。
4. 更少的內存消耗。既然操作系統為本地組件提供了優化，這一點就容易理解了。 [之前的文章說過組件類型和特征(有時也有特性)這兩個概念，三者分別基于兩類組件使用原則實現，本地模擬比起真正的仿真模擬確實有不足之處，這種不足并不僅僅是效果上的缺失，見下面的數據輸送時間部分] As to disadvantages: 不足之處：
1. Not a standard library shipped by JRE. Therefore you have to bundle them together with your applications. Also you have to build separate installers for every operating systems which you are to support.
2. Immature and unstable. SWT due to its many design defect, for example resource management, and Windows-friendly design, is said to be unstable. It can perform very well on Windows. But on non-Windows operating systems, it is unstable and crashes very often. This is largely due to the fact that SWT leaves the resource management task to developers. However, not all developers can handle resource management correctly.
3. Bad performance on non-Windows. As it is mentioned in No. 2, SWT is designed to accommodate Windows API, which results in bad performance on non-Windows platforms. The end results include slow performance, bad UI feelings, unstable or even memory leaks.
4. No Look And Feel support. The same reason as those of AWT.
5. Not extensible. The same reason as those AWT. In SWT, you can extend the component in a limited manner. For example, you can listen to the PAINT event and add custom drawing on the component. But it is very limited, since you can only control part of drawing process. You can only make up after the operating system draws the component. This is very bad for customization. Many modern applications needs such ability to provide customized behavior.
1. 不在JRE的標準庫中。因此你必須將它和你的程序捆綁在一起，并為你所要支持的每個操作系統創建單獨的安裝程序。 2. 不夠成熟和穩定。SWT因其設計上的一些缺陷，如資源管理，Windows友好等，被認為是不穩定的。它可以在Windows上表現得很好，但在其他操作系統上，它經常是不穩定且容易崩潰的。這很大程度上是因為它把資源管理交給開發者來處理，而并不是所有的開發人員能夠正確地處理這些。 3. 在非Windows平臺下的性能不高。如同第2點提到的，SWT被設計為與Windows API相協調的，這導致了在非Windows平臺上的性能問題，糟糕的UI感官，不穩定甚至內存泄露。 4. 無Look And Feel 支持。和AWT同樣的原因。 5. 不可擴展，和AWT同樣的原因。在SWT中你可以通過有限的方式擴展一個組件，例如，監聽PAINT事件并添加自定義繪圖到組件上，但鑒于你只能控制繪制處理的一部分，這是十分有限的。你也只能在操作系統繪制完組件后補充，這并不能很好支持自定義。許多應用程序在自定義行為上有很高的要求。 [并不是所以的非Windows平臺都是美觀的mac或ubuntu，薄弱的操作系統圖形支持在大的范圍內是及其普遍的。]
Swing
Swing is the most powerful GUI toolkits. It has many advantages as well as disadvantages over the other two.
Swing是三者中最強大的GUI工具集。它和另外兩者相比同樣有自己的優劣勢。
1. Rich component types. Swing provide very wide variety of standard components. These components are as rich as those SWT. Besides these standard components, Swing has a lots of third part components, due to its extensible nature. There are many commercial and open source swing libraries on market after years of development. 豐富的組件類型。Swing提供了非常廣泛的標準組件。這些組件和SWT一樣豐富。基于它良好的可擴展性，除了標準組件，Swing還提供了大量的第三方組件。許多商業或開源的Swing組件庫在開發多年后都已經可以方便地獲取了。[標準庫中確實談不上全面，但第三方組件的加入絕對媲美SWT了]
2. Rich component features. Not only swing combines all the feature on every platform, it can even provide additional feature according to the platform the applications are running on. Swing component features are designed following principle. And also swing components are very easy to be extended, therefore, swing components can usually provide much more functionalities than its SWT and AWT counterparts.豐富的組件特性。Swing不僅包含了所有平臺上的特性，它還支持根據程序所運行的平臺來添加額外特性。Swing組件特性遵循特定原則，易于擴展，因此能夠提供較SWT和AWT更多的功能。
3. Good component API and model support. Swing is designed following MVC pattern, which is proved to be a very successful design pattern. Its API are mature and well designed. After years of evolution, Swing component APIs are becoming more and more powerful, flexible and extensible. Its API design is considered to be one of the most successful GUI API. They are more Object-Oriented, more flexible and more extensible compared to SWT and AWT. 好的組件API好模型支持。Swing遵循MVC模式，這是一種非常成功的設計模式。它的API成熟并設計良好。經過多年的演化，Swing組件APIs變得越來越強大，靈活和可擴展。它的API設計被認為是最成功的GUI API之一。較之SWT和AWT更面向對象，也更靈活而可擴展。
4. Excellent Look And Feel support. MVC design model enables Swing the ability to separate component view from its data model. It has superior UI delegation which delegate UI rendering to UI classes. These classes are registered in an object, which represents a specific Look And Feel. There are now hundreds of LookAndFeel libraries available, which provides all kinds of different flavors of GUI styles. You can even write your own LookAndFeel based on others work. 出色的Look And Feel支持。MVC設計模型允許Swing分離組件試圖和它的數據模型。它有高級的UI委托來將UI渲染委托給UI類。這些類被注冊到一個展現特定的Look And Feel的對象上。已經有上百個Look And Feel 可以提高各種各樣的GUI風格。你甚至可以基于其他人的成果編寫組件的Look And Feel 。
5. Standard GUI library. Swing as well as AWT is a standard library of JRE. Therefore, you don't have to ship them separately with your application. You don't have to worry about platform incompatibility since they are platform independent.標準的GUI庫。Swing和AWT一樣是JRE中的標準庫。因此，你不用單獨地將它們隨你的應用程序一起分發。它們是平臺無關的，所以你不用擔心平臺兼容性。
6. Stable and mature. Swing has been developed for more than 7 years. It is becoming more and more mature and stable especially after Java 5. Since it is purely implemented in java, therefore, it has not such compatibility issues as those of SWT. Swing performs equally on every platforms. There are no drastically performance difference between them.成熟穩定。Swing已經開發出來7年之久了。在Java5之后它變得越來越成熟穩定。由于它是純Java實現的，不會有SWT的兼容性問題。Swing在每個平臺上都有相同的性能，不會有明顯的性能差異。
7. Extensible and flexible. Swing is a library entirely implemented in Java space. Therefore, it controls everything it needs. The architecture of Swing conforms to MVC pattern which exerts many of the advantage of Java as an Object-Oriented languages. In fact, it provides several ways to extend the components. Let me briefly enumerate them. A. Extend existing components. B. Extending by composite components. C. Writing custom components using Jcomponent from scratch. D. Using renderer and editor mechanism to extend complex swing components such as Jlist, JcomboBox, Jtable, Jtree etc. E. Creating a new LookAndFeel either by extending existing LookAndFeel or writing a new one from scratch. F. Using LayeredPane, GlassPane or Drag and Drop mechanism to develop advanced components, such as docking components, custom popup windows, custom menus etc. 可擴展和靈活性。Swing完全在Java空間中實現。它可以控制它所需要的一起。Swing基于MVC的結構使得它可以發揮Java作為一門面向對象語言的優勢。它提供了許多擴展組件的方法。讓我們來列舉一下：A.繼承已有組件；B.靠復合組件的方式擴展。C.從零開始使用JComponent編寫自定義組件；D.使用渲染器和編輯器機制擴展復制的Swing組件，如JList，JComboBox，JTable，JTree等；E.基于已有Look And Feel 或從零開始創建新的Look And Feel；F.使用LayeredPane，GlassPane或拖放機制開發高級的組件，例如浮動的固定組件，自定義彈出窗口，自定義菜單等。[這是一種好的機制，但你不能指望別人永遠無法超越你。]
8. Good overall performance. Swing has ever been mocked for its speed. However, with the development of JRE, Swing is performing better and better now. Especially after Java 5, Swing's overall speed can compete with any native widget systems. 總體上良好的性能。Swing的速度是其為人詬病的一點。然而隨著JRE的開發，Swing的性能如今已經有了很大的提高。特別是Java5之后，Swing的總體速度能夠接近本地小控件系統。
A GUI speed can usually be measured in two aspects. One is response time, and the other is data feeding time. 一個GUI的速度總是從兩個方面被衡量：響應時間和數據反饋時間。 Response time means the period between the time an event takes place and the time the component updates its UI. For example pressing a button, dragging a component, changing a tabbed pane selection, etc. In this aspect, native components usually have better response time than an emulated one. AWT and SWT components usually have better response time than those of Swings. However this is not always true. It depends on the operating systems. If native components are not implemented well on that platform, it might be the contrary. For example, Windows usually have their GUI library polished very well, while Linux platforms usually don't do well. Therefore, SWT can perform better than Swing on Windows, but might perform worse than Swing on Linux. In one word, the performance of AWT/SWT depends the underlying platforms. With the development of JRE, Swing response performance has been greatly enhanced due to JVM optimization, better swing implementation, graphics hardware acceleration etc. Swing in Java 6 can even compete with SWT on Windows. On non-Windows, Swing has much better response time than SWT.響應事件指從事件任務出現到組件更新UI的這段時間。例如按下一個按鈕，拖動一個組件，改變一個多標簽面板等。在這個方面本地組件總能比模擬組件有更好的響應。AWT和SWT通常比Swing表現出更好的響應時間。然而事實并非總是如此。這取決于操作系統。如果本地組件沒有被良好的實現，那結果就是相反的。例如Windows開發了不錯的GUI庫，而Linux平臺通常差得較遠。SWT可能在Windows上表現得比Swing好，而在Linux上表現得比Swing差。也就是說，AWT/SWT的性能決定于底層平臺。隨著JRE的開發，Swing的響應性能能夠隨著JVM的優化，更好的實現方式，以及圖形硬件加速而得到長足的改進。在Windows上，Java6的Swing可以媲美SWT的性能。在非Windows環境中，Swing可以表現出更好的響應時間。
Data feeding time means the time that is taken to transmit application data to UI components. For example, a student management software is asked to load some students information from the database and display them on a table. The time spent on transmitting those students from the memory to the table components is called feeding time. In this aspect, Swing usually performs better than the other two. It is
not so obvious when there are not much data to be fed. But if there are tremendous data to be fed into the table, it is becoming more and more noticeable. Why? To understand it, you have to be reminded that JVM and native operating systems are two separate running environment. JNI call made by java program usually consumes much more time than ordinary java call. It is obvious that JNI call is an action that spans two different systems. When a JNI invocation happens, it usually involves two process. One is that Java data structure is translated into native system structure. And second, when a method returns, the returned values should also be translated into java objects. Not to mention other performance costs. When a large bound array of data are fed to native component, there will be large amount of JNI call which can drastically slow down the performance. 數據輸送時間是指用于將應用程序數據傳遞給UI組件所需要的時間。例如，一個學生管理系統要求從數據庫中裝載學生信息并在一個表格中顯示出來。花費在從內存到表格組件的數據傳遞時間被稱為數據輸送時間.在這個方面，Swing通常比其他二者的性能更好。或許當數據量不大的情況下并不明顯。但當海量的數據被輸送給表格的時候，這一點就顯而易見了。為了理解這一點，提醒你注意JVM和本地操作系統是兩個分離的運行時環境。由于JNI的調用在兩個環境中跨越式地發生，通常比一個普通的Java調用花費更長的時間。通常這包含兩個處理。一個是Java數據結構轉換為本地數據結構，另一個是方法返回時的本地數據結構轉換為Java對象。其他的性能開銷暫時忽略不計。當一個大范圍數組的數據從本地組件中輸送過來，大量反復的JNI調用將極大地拖垮性能。[記起了blogjava上阿南的那個問題，或許，正是這個原因吧，數組也是對象，所以轉換也不會是簡單的] And anther swing advantage is that it has many component models which can speed up the feeding performance greatly. For example tablemodel can be mapped to a two dimension array. In such case, there is even no data transmission happened in Swing components. Swing table directly displays the application data to the screen, greatly eliminating the time spent on data transmission. Swing的另一個優勢是它有許多的組件模型以提高輸送的性能。例如TableModel被映射為兩個維度上的數組。這樣，在Swing組件中甚至不需要進行數據方式的轉換。Swing表直接將應用程序數據顯示在屏幕上，節省了在數據轉換上所花費的事件。 As to Swing's disadvantages: Swing也有不足之處：
1. More memory consumption than AWT and SWT. Swing has all its components implemented by itself. Therefore, it has much more classes to be loaded in runtime. There are some other issues such as small mutable object creation, such as Rectangle, Point etc, these objects usually cannot be re-used due to synchronization consideration. Java creates all the objects on the heap. And small objects can often waste heap space. These small objects garbages can not be collected efficiently compared to large objects. Therefore, Swing application often creates a lots of small objects which can not be collected in time. More often it can result in performance degradation.比AWT和SWT更多的內存消耗。Swing自己實現了所有組件。因此，它在運行時裝載了大量的類。一些其他的問題來源于小的可變對象的創建，如Rectangle，Point，這些對象基于同步的考慮通常不可重用。Java在堆上創建所以對象。小的對象通常導致了額外的堆空間消耗。許多小的對象較之大對象更難以有效地被垃圾回收。因此，Swing應用程序通常無法及時回收大而小的對象。這種情況的普遍就會導致性能下降。[通過研讀一些gc方面的文章，你會對gc有更深入的了解，并懂得如何設計好的對象使用方式和生命周期。另外，component.getBounds(r)之類的方法不會自己創建新的Rectangle，也算一個變通吧]
2. More application startup time. Now JVM is fast enough. Some people even said it can even compete with some C++ implementation. But still there are some java application which seem to be very slow. In fact, many java performance issues are caused by class loading. Class loading is an I/O operation which can greatly slow down java applications. Perhaps this is the issue that every dynamic linking system must face. Swing application usually involves thousands of thousand Swing classes. Before Swing application can show its main window, it
has loaded much more classes than AWT and SWT applications. This can greatly increase Swing application startup time. If Swing classes are pre-loaded as shared system libraries, this issue can be resolved easily. 更多的啟動時間。現在JVM已經快得多了。許多人甚至揚言它可以媲美C++的實現。但多數的Java應用程序還是看上去很慢。實際上，Java性能的很多問題來源于類裝載機制。這是一個I/O操作，故而能夠明顯地降低Java應用程序的速度。也許這是每個動態鏈接系統中都要面對的問題吧。Swing通常包含了上千個Swing類的使用，在Swing應用程序可以顯示它的主窗口之前，它比AWT或SWT裝載了多得多的類。這嚴重降低了Swing的啟動時間。這種問題也許會相對好一點如果Swing的類是以共享系統庫的方式預加載的。[冷啟動的問題嗎？這種機制是操作系統的特性了，java可能以系統服務的方式出現嗎？這個可要好好論證不能盲目做]
The above comparison is mainly conducted in technical perspective. There are many other terms which should be considered when you choose a toolkit. For example, documentation, support, learning curves and community etc. But since we are focusing their technical sides, we shall not detail them here.上述的比較總的來說是技術上的總結。相對其他方面的因素也會影響你對一個工具集的選擇。例如，文檔，支持，學習曲線和社區等，但既然我們關注的是技術層面，就不在這里講的太多了。 (End)
芳兒寶貝.我愛你
