原文：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級(jí)別上的。讓我們將比較的焦點(diǎn)轉(zhuǎn)移到實(shí)現(xiàn)細(xì)節(jié)上。Swing和SWT/AWT的區(qū)別是Swing是純Java實(shí)現(xiàn)，而SWT和AWT是Java和JNI的混合。當(dāng)然，它們的目標(biāo)都是相同的，提供一個(gè)跨平臺(tái)的APIs。然而為了達(dá)到這一點(diǎn)，SWT和AWT不得不犧牲一些組件和特性以提供一個(gè)通用的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.
一個(gè)AWT組件通常是一個(gè)包含了對(duì)等體接口類(lèi)型引用的組件類(lèi)。這個(gè)引用指向本地對(duì)等體實(shí)現(xiàn)。舉java.awt.Label為例，它的對(duì)等體接口是LabelPeer。LabelPeer是平臺(tái)無(wú)關(guān)的。在不同平臺(tái)上，AWT提供不同的對(duì)等體類(lèi)來(lái)實(shí)現(xiàn)LabelPeer。在Windows上，對(duì)等體類(lèi)是WlabelPeer，它調(diào)用JNI來(lái)實(shí)現(xiàn)label的功能。這些JNI方法用C或C++編寫(xiě)。它們關(guān)聯(lián)一個(gè)本地的label，真正的行為都在這里發(fā)生。作為整體，AWT組件由AWT組件類(lèi)和AWT對(duì)等體提供了一個(gè)全局公用的API給應(yīng)用程序使用。一個(gè)組件類(lèi)和它的對(duì)等體接口是平臺(tái)無(wú)關(guān)的。底層的對(duì)等體類(lèi)和JNI代碼是平臺(tái)相關(guān)的。
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的方法論來(lái)實(shí)現(xiàn)。但細(xì)節(jié)不同于AWT。SWT的擁護(hù)者聽(tīng)到人們拿SWT和AWT相提并論可是會(huì)很生氣的，Steve Northover，SWT之父，就曾為此抱怨過(guò)。
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.
沒(méi)錯(cuò)，它們是不同的。讓我們深究SWT的代碼。在SWT中，各個(gè)平臺(tái)上唯一相同的部分是組件的接口，是類(lèi)和方法的定義簽名。所有的底層代碼都是平臺(tái)差異的。SWT為每個(gè)平臺(tái)提供了OS類(lèi)。這個(gè)類(lèi)用JNI封裝了許多本地APIs。SWT組件類(lèi)通過(guò)把這些JNI方法黏合在一起提供一個(gè)有意義的功能。
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上，文本域的選擇是由一個(gè)系統(tǒng)調(diào)用處理的。這個(gè)系統(tǒng)調(diào)用在Windows的OS類(lèi)中作為一個(gè)本地方法實(shí)現(xiàn)。所以在Windows平臺(tái)的Text的setSelection方法中只用到了一個(gè)JNI調(diào)用。
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上，文本域的選擇包含兩個(gè)本地調(diào)用。SWT就在motif的OS類(lèi)中實(shí)現(xiàn)了兩個(gè)調(diào)用。所以在motif上組件類(lèi)需要作兩次調(diào)用來(lái)實(shí)現(xiàn)文本的選擇。
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.
現(xiàn)在你應(yīng)該能看出SWT和AWT的最大不同了，它們使用了不同的對(duì)等體編程方式來(lái)消除平臺(tái)差異。SWT用java代碼或有JNI實(shí)現(xiàn)的java對(duì)等體來(lái)黏合系統(tǒng)調(diào)用。而AWT把代碼包含在對(duì)等體中，使情況復(fù)雜化了，我個(gè)人覺(jué)得SWT的方法更加明智。[是否我翻譯有問(wèn)題，因?yàn)槲也⒉挥X(jué)得是這樣更明智，SWT的無(wú)則模擬是不必要的，這是使用者才去做的事，SWT作為提供者應(yīng)該無(wú)則C++實(shí)現(xiàn)，當(dāng)然實(shí)現(xiàn)的是最核心的高度復(fù)用的又或者需要極大性能支持的，畢竟帶了動(dòng)態(tài)鏈接庫(kù)，索性多放點(diǎn)東西。]
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的實(shí)現(xiàn)不依賴(lài)于具體平臺(tái)。它掌管了所有的控制和資源。Swing所需要的是事件輸入來(lái)驅(qū)動(dòng)系統(tǒng)，以及承接自頂層AWT容器的圖形處理，字體和顏色。普通的Swing組件可以看作是AWT容器的一塊邏輯區(qū)域。它們并沒(méi)有注冊(cè)對(duì)等體。所有添加到同一頂層容器的Swing組件共享它的AWT對(duì)等體以獲取系統(tǒng)資源，如字體，圖形處理等。Swing將組件自己的數(shù)據(jù)結(jié)構(gòu)存儲(chǔ)在JVM的空間中。它完全由自己管理畫(huà)圖處理，事件分發(fā)和組件布局。
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都持有對(duì)本地組件的引用，它們必須以正確的方式釋放這些引用以避免內(nèi)存泄露和JVM崩潰。AWT將絕大多數(shù)資源管理任務(wù)交給系統(tǒng)，將開(kāi)發(fā)者從單調(diào)乏味的資源管理中解救出來(lái)。然而這使得AWT的實(shí)現(xiàn)復(fù)雜化了。一旦它實(shí)現(xiàn)了，開(kāi)發(fā)者很少有機(jī)會(huì)犯錯(cuò)誤并使他們的程序崩潰。
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讓開(kāi)發(fā)者自己來(lái)管理資源。它的一條著名的規(guī)則是：誰(shuí)創(chuàng)建，誰(shuí)釋放。因此開(kāi)發(fā)者必須謹(jǐn)慎地顯式調(diào)用dispose方法釋放每一個(gè)由他創(chuàng)建的組件和資源。這簡(jiǎn)化了SWT的實(shí)現(xiàn)模型，但把開(kāi)發(fā)者擺在了因錯(cuò)誤編碼而易于造成程序崩潰這一風(fēng)險(xiǎn)之上。
Emulation difference模擬方式的區(qū)別
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在它們的實(shí)現(xiàn)上都使用了模擬。SWT只模擬平臺(tái)上缺失的組件。區(qū)別是SWT的模擬更像是AWT的Canvas實(shí)現(xiàn)的模擬。SWT的Composite類(lèi)有它自己在操作系統(tǒng)中相應(yīng)的對(duì)等體。它從自己的對(duì)等體中獲得所有它所需要的資源如圖形處理的對(duì)象，字體和顏色等。它直接從操作系統(tǒng)獲取所有的事件并進(jìn)行處理。然而，Swing組件在操作系統(tǒng)中沒(méi)有相應(yīng)的對(duì)等體。它只是一塊頂層容器中的邏輯區(qū)域，實(shí)際上它從頂層容器的對(duì)等體中借用資源。Swing的事件并不是底層系統(tǒng)產(chǎn)生的事件。它們實(shí)際是由頂層容器處理AWT事件所產(chǎn)生的偽事件。我們會(huì)在稍后的事件部分中詳細(xì)介紹它。
Graphical Layer Architecture圖形層結(jié)構(gòu)
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.
另一個(gè)不同之處是Swing組件的z-order系統(tǒng)是來(lái)自于AWT組件的。如上所述，Swing組件與頂層AWT容器共享一個(gè)對(duì)等體。因此，Swing組件也和頂層容器有相同的z-order。SWT和AWT組件都有不同于頂層容器的z-order，通常是高于頂層容器。故而如果AWT組件和Swing組件混合在一起的話，Swing組件將可能被AWT組件遮住。當(dāng)操作系統(tǒng)開(kāi)始更新UI的時(shí)候，頂層容器和Swing組件總是先于AWT組件繪制。當(dāng)它們完成繪制，AWT組件會(huì)覆蓋Swing可能繪制過(guò)的地方。因此不提倡Swing和AWT組件的混用。如果有一個(gè)浮動(dòng)的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.
并不是三者中的所有部分都是不同的。布局管理器是一個(gè)例外。開(kāi)發(fā)GUI應(yīng)用程序，當(dāng)容器改變大小的時(shí)候，組件需要重定位或改變大小。在傳統(tǒng)的編程語(yǔ)言中，這依靠監(jiān)聽(tīng)大小改變的事件來(lái)實(shí)現(xiàn)。相應(yīng)的片段散落在源代碼的各個(gè)角落降低了程序的可讀性。Java引入了將布局代碼封裝的思路，稱(chēng)之為布局管理器。當(dāng)布局管理器對(duì)象被設(shè)置到一個(gè)容器中，它自動(dòng)處理大小改變的事件。當(dāng)大小改變時(shí)，管理器的布局方法被調(diào)用以重定位子組件或調(diào)整它們的形狀。
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都以這樣的方式來(lái)組織，而都有它們各種獨(dú)特的布局管理器。由于AWT和Swing擁有一個(gè)共同的超類(lèi)java.awt.Component，它們的布局管理器可以交替地使用。
(To be continued ...)