原文：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，它們的布局管理器可以交替地使用。
(To be continued ...)