AWT
AWT是Sun不推荐使用的工具集。然而它在许多非桌面环境如移动或嵌入式设备中有着自己的优势。
更少的内存。它对运行在有限环境中的GUI程序的开发，是合适的。
1.更少的启动事件。由于AWT组件是本地由操作系统实现的。绝大多数的二进制代码已经在如系统启动的时候被预装载了，这降低了它的启动事件。
2.更好的响应。由于本地组件由操作系统渲染。
3.从java 1.x时代就为JRE支持的标准GUI工具集，你不用单独安装它，你不用担心平台差异的问题。
4.成熟稳定的。它能够正常工作并很少使你的程序崩溃。
然而，事物都有它们不好的一面。让我们来例数它吧。
1. 更少的组件类型。表和树这些重要的组件缺失了。它们是桌面应用程序中普遍使用的。
2.缺乏丰富的组件特征。按钮不支持图片附着。这很明显是它遵循的设计原则造成的。
3.不支持Look And Feel。AWT被设计为使用本地组件。因此，它依赖系统来提供Look And Feel支持。如果目标系统并不支持这一特性，那么AWT将无法改变它的Look And Feel。
4.无扩展性。AWT的组件是本地组件。JVM中的AWT类实例实际只是包含本地组件的引用。唯一的扩展点是AWT的Canvas组件，你可以从零开始创建自定义组件。然而无法继承和重用一个已有的AWT组件。
SWT
SWT有如下优势：
1.丰富的组件类型。SWT提供了种类繁多的组件，从基础组件如按钮和标签到高级的表格和树。
2.相对的丰富组件特性。尽管SWT也遵循最大公倍数原则，它采用模拟的方式重新设计了对更多组件特性的支持。所以同AWT相比，它有着相对丰富的组件特性。
3.更快的响应时间。基于和AWT同样的原因，SWT组件包装了本地组件，由操作系统实现渲染。操作系统通常对渲染处理做了优化，保存GUI二进制代码为标准库，减少了内存的使用，提高了响应性能。
4.更少的内存消耗。既然操作系统为本地组件提供了优化，这一点就容易理解了。
不足之处：
1.不在JRE的标准库中。因此你必须将它和你的程序捆绑在一起，并为你所要支持的每个操作系统创建单独的安装程序。
2.不够成熟和稳定。SWT因其设计上的一些缺陷，如资源管 理，Windows友好等，被认为是不稳定的。它可以在Windows上表现得很好，但在其他操作系统上，它经常是不稳定且容易崩溃的。这很大程度上是因 为它把资源管理交给开发者来处理，而并不是所有的开发人员能够正确地处理这些。
3.在非Windows平台下的性能不高。如同第2点提到的，SWT被设计为与Windows API相协调的，这导致了在非Windows平台上的性能问题，糟糕的UI感官，不稳定甚至内存泄露。
4.无Look And Feel 支持。和AWT同样的原因。
5.不可扩展，和AWT同样的原因。在SWT中 你可以通过有限的方式扩展一个组件，例如，监听PAINT事件并添加自定义绘图到组件上，但鉴于你只能控制绘制处理的一部分，这是十分有限的。你也只能在操作系统绘制完组件后补充，这并不能很好支持自定义。许多应用程序在自定义行为上有很高的要求。
SWING
Swing是三者中最强大的GUI工具集。它和另外两者相比同样有自己的优劣势。
1、丰富的组件类型。Swing提供了非常广泛的标准组件。这些组件和SWT一样丰富。基于它良好的可扩展性，除了标准组件，Swing还提供了大量的第三方组件。许多商业或开源的Swing组件库在开发多年后都已经可以方便地获取了。
2、丰富的组件特性。Swing不仅包含了所有平台上的特性，它还支持根据程序所运行的平台来添加额外特性。Swing组件特性遵循特定原则，易于扩展，因此能够提供较SWT和AWT更多的功能。
3、好 的组件API模型支持。Swing遵循MVC模式，这是一种非常成功的设计模式。它的API成熟并设计良好。经过多年的演化，Swing组件APIs变得 越来越强大，灵活和可扩展。它的API设计被认为是最成功的GUI API之一。较之SWT和AWT更面向对象，也更灵活而可扩展。
4、出 色的Look And Feel支持。MVC设计模型允许Swing分离组件视图和它的数据模型。它有高级的UI委托来将UI渲染委托给UI类。这些类被注册到一个展现特定的 Look And Feel的对象上。已经有上百个Look And Feel 可以提高各种各样的GUI风格。你甚至可以基于其他人的成果编写组件的Look And Feel 。
5、标准的GUI库。Swing和AWT一样是JRE中的标准库。因此，你不用单独地将它们随你的应用程序一起分发。它们是平台无关的，所以你不用担心平台兼容性。
6、成熟稳定。Swing已经开发出来7年之久了。在Java5之后它变得越来越成熟稳定。由于它是纯Java实现的，不会有SWT的兼容性问题。Swing在每个平台上都有相同的性能，不会有明显的性能差异。
7、可扩展和灵活性。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、总体上良好的性能。Swing的速度是其为人诟病的一点。然而随着JRE的开发，Swing的性能如今已经有了很大的提高。特别是Java5之后，Swing的总体速度能够接近本地小控件系统。
一个GUI的速度总是从两个方面被衡量：响应时间和数据反馈时间。
响应事件指从事件任务出现到组件更新UI的这段时间。例如按下 一个按钮，拖动一个组件，改变一个多标签面板等。在这个方面本地组件总能比模拟组件有更好的响应。AWT和SWT通常比Swing表现出更好的响应时间。 然而事实并非总是如此。这取决于操作系统。如果本地组件没有被良好的实现，那结果就是相反的。例如Windows开发了不错的GUI库，而Linux平台 通常差得较远。SWT可能在Windows上表现得比Swing好，而在Linux上表现得比Swing差。也就是说，AWT/SWT的性能决定于底层平 台。随着JRE的开发，Swing的响应性能能够随着JVM的优化，更好的实现方式，以及图形硬件加速而得到长足的改进。在Windows上，Java6 的Swing可以媲美SWT的性能。在非Windows环境中，Swing可以表现出更好的响应时间。
数据输送 时间是指用于将应用程序数据传递给UI组件所需要的时间。例如，一个学生管理系统要求从数据库中装载学生信息并在一个表格中显示出来。花费在从内存到表格 组件的数据传递时间被称为数据输送时间.在这个方面，Swing通常比其他二者的性能更好。或许当数据量不大的情况下并不明显。但当海量的数据被输送给表 格的时候，这一点就显而易见了。为了理解这一点，提醒你注意JVM和本地操作系统是两个分离的运行时环境。由于JNI的调用在两个环境中跨越式地发生，通 常比一个普通的Java调用花费更长的时间。通常这包含两个处理。一个是Java数据结构转换为本地数据结构，另一个是方法返回时的本地数据结构转换为 Java对象。其他的性能开销暂时忽略不计。当一个大范围数组的数据从本地组件中输送过来，大量反复的JNI调用将极大地拖垮性能。
Swing的另一个优势是它有许多的组件模型以提高输送的性能。例如TableModel被映射为两个维度上的数组。这样，在Swing组件中甚至不需要进行数据方式的转换。Swing直接将应用程序数据显示在屏幕上，节省了在数据转换上所花费的事件。
Swing也有不足之处：
比AWT和SWT更多的内存消耗。Swing自己实现了所有组件。因此，它在运行时装载了大量的类。一些其他的问题来源于小的可变对象的 创建，如Rectangle，Point，这些对象基于同步的考虑通常不可重用。Java在堆上创建所以对象。小的对象通常导致了额外的堆空间消耗。许多 小的对象较之大对象更难以有效地被垃圾回收。因此，Swing应用程序通常无法及时回收大而小的对象。这种情况的普遍就会导致性能下降。
更 多的启动时间。现在JVM已经快得多了。许多人甚至扬言它可以媲美C++的实现。但多数的Java应用程序还是看上去很慢。实际上，Java性能的很多问 题来源于类装载机制。这是一个I/O操作，故而能够明显地降低Java应用程序的速度。也许这是每个动态链接系统中都要面对的问题吧。Swing通常包含 了上千个Swing类的使用，在Swing应用程序可以显示它的主窗口之前，它比AWT或SWT装载了多得多的类。这严重降低了Swing的启动时间。这 种问题也许会相对好一点如果Swing的类是以共享系统库的方式预加载的。
摘自：http://blog.csdn.net/kjfcpua/article/details/5981384