原文：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對象作為參數。
(To be continued ...)