Why did we implement Swing in this way?（为什么Swing要这样实现呢？）

我翻译的不好的地方大家多多担待。请多多指教。

There are several advantages in executing all of the user interface code in a single thread:
因为在一个线程里执行用户界面代码有以下优点：
  * Component developers do not have to have an in-depth understanding of threads programming: Toolkits like ViewPoint and Trestle, in which all components must fully support multithreaded access, can be difficult to extend, particularly for developers who are not expert at threads programming. Many of the toolkits developed more recently, such as SubArctic and IFC, have designs similar to Swing's.
*组件开发人员不需要深入理解线程编程：像ViewPoint和Trestle这样的工具包，它们之中的所有组件必须完全支持多线程访问，所以很难运用它们来编程，特别是不精通线程编程的开发人员。许多像SubArctic和IFC这样最近开发的工具包都和Swing有相似的设计。
   
  * Events are dispatched in a predictable order: The runnable objects enqueued by invokeLater() are dispatched from the same event queue as mouse and keyboard events, timer events, and paint requests. In toolkits where components support multithreaded access, component changes are interleaved with event processing at the whim of the thread scheduler. This makes comprehensive testing difficult or impossible.
*用一个可以预见的方式来分发事件：invokeLater()通过分发同一事件队列中的运行对象像鼠标和键盘事件、计时器事件和画图请求来进行排队。一个在支持多线程访问的工具包中的组件改变是错综复杂的因为事件是按各自线程调度(就是具有不可预见性)来进行的。这就使得全面的测试困难或者不可能实现。
  * Less overhead: Toolkits that attempt to carefully lock critical sections can spend a substantial amount of time and space managing locks. Whenever the toolkit calls a method that might be implemented in client code (for example, any public or protected method in a public class), the toolkit must save its state and release all locks so that the client code can grab locks if necessary. When control returns from the method, the toolkit must regrab its locks and restore its state. All applications bear the cost of this, even though most applications do not require concurrent access to the GUI.
*减少开销：工具包要花费特别巨大的时间和空间去管理那些工具包小心翼翼给危险局域加的锁。当这个工具包调用一个客户端编写的方法时，工具包必须保存自己的状态和释放所有需要释放的锁，以便客户端获取锁。当调用客户端代码完毕时，工具包必须重新获得刚才释放的锁和加载刚才的状态。(这是非常耗时间和空间的事情，而且对于不精通线程编程的人来说是一个灾难。而且在维护的时候也是非常困难的。)这些消耗在所有应用程序中都是占非常大的，甚至使得很多应用程序不能够顺利的进行图形界面操作。

  Here's a description, written by the authors of the SubArctic Java Toolkit, of the problem of supporting multithreaded access in a toolkit:
这是SubArctic JavaToolkit作者写一个支持多线程访问的工具包中问题的说明：  
It is our basic belief that extreme caution is warranted when designing and building multi-threaded applications, particularly those which have a GUI component. Use of threads can be very deceptive. In many cases they appear to greatly simplify programming by allowing design in terms of simple autonomous entities focused on a single task. In fact in some cases they do simplify design and coding. However, in almost all cases they also make debugging, testing, and maintenance vastly more difficult and sometimes impossible. Neither the training, experience, or actual practices of most programmers, nor the tools we have to help us, are designed to cope with the non-determinism. 
小心谨慎是我们的基本信念当设计和编写多线程应用程序时，特别是那些有图形界面组件的应用程序。线程使用具有非常的欺骗性。在很多项目它们显得非常容易编写通过允许设计简单独立的针对一个单独任务的实体对象。(就是说设计一个线程处理一个任务，这个任务中只有一个实体对象)实际上在有些项目线程让设计和编码更加简单。然而几乎所有的项目线程都使调试、测试和维护变得更加困难得多或者不可实现。大多数程序员的培训、经验或者实战练习和专门为不是决定性判断的工具都不能帮助我们(大多数程序的努力(天才除外比如像他们这些编写人员，不过对脑细胞具有非常的杀伤力)和专门的工具都不能帮助我们解决前述多线程引起的问题)。
For example, thorough testing (which is always difficult) becomes nearly impossible when bugs are timing dependent. This is particularly true in Java where one program can run on many different types of machines and OS platforms, and where each program must work under both preemptive or non-preemptive scheduling.
例如，当bugs和时间相关联时，测试几乎无法进行。这一点在Java上尤其突出因为Java做出来的程序是跨平台的，它可以在不同类型的机器和不同操作系统上运行，程序也必须在抢占式和非抢占式调用下运行。(如果bug因为时间关系才能出现，那么测试这个代码几乎是不可能的事情。这一点在Java上表现出来就特别明显。因为Java是跨平台的，所以就需要面临不用的机器和操作系统，随之而来的是不同的调度方式（抢占式和非抢占式）。所以呢，如果事件是同时被触发而且没有一个队列来保证它们的先后顺序，那么结果就可想而知了。不同操作系统的调度方式不一样造成事件处理的先后顺序不一样，那么结果也不一样。)
As a result of these inherent difficulties, we urge you to think twice about using threads in cases where they are not absolutely necessary. However, in some cases threads are necessary (or are imposed by other software packages) and so subArctic provides a thread-safe access mechanism. This section describes this mechanism and how to use it to safely manipulate the interactor tree from an independent thread.
由于这些固有的问题(实现的时候的困难)，我们建议你在项目中使用多线程前多想想如果不是必须使用多线程的时候。然而，在一些项目中多线程是必须的，所以subArctic提供了以个线程安全的访问机制。这部分详细说明了这个机制和怎么去安全的使用它们。
The thread-safe mechanism they're referring to is very similar to the invokeLater() and invokeAndWait() methods provided by the SwingUtilities class.
这个线程安全机制就是被大家经常提到的SwingUtilities提供的invokeLater()和invokeAndWait()方法。