一、【转】http://www.cnblogs.com/dugang/archive/2010/10/22/1858478.html
AWT
AWT是Abstract Window Toolkit（抽象窗口工具包）的缩写，是SUN专门针对Java GUI编程提供的最早的也是最初的开发工具包，用来建立和设置Java图形用户界面，这个工具包提供了一套与本地图形界面交互的接口。AWT 中的图形函数与操作系统所提供的图形函数之间有着一一对应的关系（peers）。也就是说，当我们利用 AWT 来构件图形用户界面的时候，实际上是在利用操作系统所提供的图形库。不过由于不同操作系统的图形库所提供的功能是不完全一样，所以在一个平台上存在的功能在另外一个平台上则可能不存在。这就导致一些应用程序在测试时界面非常美观，而一旦移植到其他的操作系统平台上后就可能变得“惨不忍睹”。为了实现Java语言"一次编译，到处运行"，AWT 不得不通过牺牲功能来实现其平台无关性，其所提供的图形功能被定格为各种通用型操作系统所提供的图形功能的交集。由于AWT 是依靠本地方法来实现其功能的，所以通常把AWT组件称为重量级组件。
AWT是Sun不推荐使用的工具集。然而它在许多非桌面环境如移动或嵌入式设备中有着自己的优势：
1.更少的内存：对运行在有限环境中的GUI程序的开发，是合适的。
2.更少的启动事件：由于AWT组件是本地由操作系统实现的。绝大多数的二进制代码已经在如系统启动的时候被预装载了，这降低了它的启动事件。
3.更好的响应：由于本地组件由操作系统渲染。
4.成熟稳定的：能够正常工作并很少使你的程序崩溃。
然而事物具有两面性，AWT也有着许多缺点：
1.更少组件类型：表和树这些重要的组件缺失了。它们是桌面应用程序中普遍使用的。
2.缺乏丰富的组件特征：按钮不支持图片。
3.无扩展性：AWT的组件是本地组件。JVM中的AWT类实例实际只是包含本地组件的引用。唯一的扩展点是AWT的Canvas组件，可以从零开始创建自定义组件。然而无法继承和重用一个已有的AWT组件
Swing
Swing 是在AWT的基础上构建的一套新的图形界面系统，是JFC（Java Foundation Class）的一部分，是试图解决AWT缺点的一个尝试。它提供了AWT 所能够提供的所有功能，并且用纯粹的Java代码对AWT 的功能进行了大幅度的扩充。所有的swing组件实际上也是AWT的一部分。Swing 对基于对等体的组件使用的术语是重量级，对于模拟的组件使用的术语是轻量级。实际上，Swing 可以支持在一个 GUI 中混合使用重量级组件和轻量级组件，不过一般将其称之为轻量级组件。
Swing是三者中最强大的GUI工具集，同时它也是SUN推荐使用的GUI工具集，通过几个本版的修改和扩展后，现在的swing在某些领域有着明显优势：
1.丰富的组件类型:Swing提供了非常广泛的标准组件。这些组件和SWT一样丰富。基于它良好的可扩展性，除了标准组件，Swing还提供了大量的第三方组件。许多商业或开源的Swing组件库在开发多年后都已经可以方便地获取了。
2.丰富的组件特性:Swing不仅包含了所有平台上的特性，它还支持根据程序所运行的平台来添加额外特性。Swing组件特性遵循特定原则，易于扩展，因此能够提供较SWT和AWT更多的功能。
3.好的组件API模型支持:Swing遵循MVC模式，这是一种非常成功的设计模式。它的API成熟并设计良好。经过多年的演化，Swing组件APIs变得越来越强大，灵活和可扩展。它的API设计被认为是最成功的GUI API之一。较之SWT和AWT更面向对象，也更灵活而可扩展。
4.标准的GUI库：Swing和AWT一样是JRE中的标准库。因此，你不用单独地将它们随你的应用程序一起分发。它们是平台无关的，不用担心平台兼容性。
5.成熟稳定：由于它是纯Java实现的，不会有SWT的兼容性问题。Swing在每个平台上都有相同的性能，不会有明显的性能差异。
6.可扩展和灵活性。Swing完全由Java代码实现。Swing基于MVC的结构使得它可以发挥Java作为一门面向对象语言的优势。它提供了许总体上良好的性能。
当然，swing也有着许多不足之处：比如swing比AWT和SWT更多的内存消耗。Swing自己实现了所有组件。因此，它在运行时装载了大量的类。而在运行时Java在堆上创建小的对象导致了额外的堆空间消耗。而许多小的对象难以有效地被垃圾回收机制回收。因此，Swing应用程序通常会因无法及时回收冗余的对象而导致性能下降。
SWT
SWT是Standard WidgetToolkit的缩写，是由IBM构建的一个新的GUI库，其目的在于尝试彻底解决AWT和swing带来的诸多问题，提供比AWT更为丰富的组件集。SWT和swing一样痛Java代码模拟了一些平台缺失的组件，不过与 AWT 的概念相比，SWT 是一个低级的 GUI 工具包，在构建SWT的过程中，构建者从 AWT 和 Swing 实现中学习了很多经验，他们试图构建一个集二者优点于一体而没有二者的缺点的系统。因此SWT可以说是AWT与swing的融合体。
SWT有如下优势：
1.丰富的组件类型：SWT提供了种类繁多的组件，从基础组件如按钮和标签到高级的表格和树。
2.相对的丰富组件特性：尽管SWT也遵循最大公倍数原则，它采用模拟的方式重新设计了对更多组件特性的支持。所以同AWT相比，它有着相对丰富的组件特性。
3.更快的响应时间：基于和AWT同样的原因，SWT组件包装了本地组件，由操作系统实现渲染。操作系统通常对渲染处理做了优化，保存GUI二进制代码为标准库，减少了内存的使用，提高了响应性能。
4.更少的内存消耗。
不足之处：
1.不在JRE的标准库中。因此必须将它和程序捆绑在一起，并为所要支持的每个操作系统创建单独的安装程序。
2.不够成熟和稳定。SWT因其设计上的一些缺陷，如资源管理，Windows友好等，被认为是不稳定的。它可以在Windows上表现得很好，但在其他操作系统上，它经常是不稳定且容易崩溃的。这很大程度上是因为它把资源管理交给开发者来处理，而并不是所有的开发人员能够正确地处理这些。
3.在非Windows平台下的性能不高4.无Look AndFeel 支持。和AWT同样的原因。
4.不可扩展。
综上所述，在对GUI编程时的工具包选择得根据具体项目决定：若是需要用低内存来运行GUI程序，使用AWT会是一个不错的选择，而如果只考虑平台的移植性可优先考虑SWT/swing
*************************************************************************
二、(转载)Java中AWT、Swing与SWT三大GUI技术的原理与效率差异
【转】http://blog.csdn.net/widegoose/archive/2005/03/30/333908.aspx
看了一下对Java GUI讨论的帖子，所以写了一篇文章来阐述一下各种GUI技术的优劣。
Java世界中，目前最知名的三大GUI库分别是：
1、AWT（Abstract Window Toolkit）抽象窗口工具包库，包含于所有的java SDK中
2、Swing高级图形库，包含于Java2 SDK中
3、来自IBM Eclipse开源项目的SWT（Standard Widget Toolkit）标准窗口部件库，不包含于JDK中，需要从Eclipse单独下载
一、AWT的原理：小巧却简陋的GUI系统
AWT出现于Java 1.x中，是Java初期所内置的一种面向窗口应用的库。AWT使用的技术是对等设计模式（即Peer），其结构关系参见下图。
从这幅类关系图很容易看出AWT的技术实现和Peer设计模式。图中，黄色的类是java.awt包中的类，浅灰色部分是Java虚拟机部分，而深灰色则是Windows平台。
awt的重点是对等Peer设计模式。所谓Peer对等设计模式就是将awt控件直接对应到运行平台上的一个类似或者等同控件上。比如图中的Button类就是对应了深灰色的Windows的标准Button功能。
对等模式用于在两个控件间之间建立一个相互作用的联系，而充当纽带的则是Java虚拟机和虚拟机－GDI的接口（以Windows为例子）。所以，我们可以看出，awt首先需要经过通用的Java技术来控制图形、事件等，然后Java虚拟机再将请求传送到具体的平台图形和控件接口去交互。
对等模式的效率并不很高，因为AWT通过了虚拟机和虚拟机－GDI这两个层次来完成一个操作，经过的层次系统越多，速度和效率就越慢。而且Peer对等模式有一个致命的弱点：移植性非常差！
这就是Sun为什么要用Swing来诱惑我们离开AWT的主要原因。因为既然是对等模式，那么AWT就必须使用所有图形操作系统的图形接口功能的交集，因为 AWT的接口只有一套，所以，为了保证移植性，就只能使用所有系统都能够支持的最少特性。因而我们经常可以听见有人抱怨AWT的功能太少，图形太难看等等，这是为了保证移植性而作出的牺牲。
二、猛犸巨兽的诞生－Swing
从Java2 即Java 1.2版本开始，Sun开始在JDK中提供一套新的图形界面接口系统－Swing。所有Java爱好者都投入了对Swing的研究和迷恋。随着一大批使用Swing作为界面技术的IDE和程序出现，很快大家都意识到Swing的问题所在。
一些人认为Swing是轻量级的GUI系统，无论官方如何说，没有一个Java程序员会认为Swing是轻量级的，相反，Swing是一个非常巨大的GUI库，这一点已经是Java界的共识。
Swing的一些底层类是借用了AWT的Component、Container、Window等少数几个基础类。估计的原因是为了保持与AWT的兼容，方便大家将代码移植到Swing上。
下面是Swing的类关系图：
菊黄色类为Swing包的类。对比一下Swing的图与AWT的图，我们可以发现，Swing图中，awt体系中的深灰色Windows控件类已经被去掉了。因为Swing不再沿用Peer对等模式来实现GUI界面。
这是Swing的核心思想之一，Swing是完全基于Java自绘制图形而实现的，因而Swing的界面看起来与Windows不再有任何类似，尤其是窗口控件的样式（虽然我们也可以通过换肤来达到模拟Windows界面的效果）。
所以上图清楚的表明了Swing是一个高层的GUI系统，而不像AWT那样与运行平台技术更加靠近的系统。我们仍然用Button与Panel来做了一个例子，图中关系看出，Swing的类继承关系比AWT要复杂的多，而且Swing类大多都经过了中间的转接类－JComponent。而我们常用的JFrame则另辟蹊径，从awt的window继承了下来。
这种结构关系决定了Swing的庞大与复杂性。很多初学者都难以理解Swing的模式和结构。
Swing 中的控件都是利用Java图形功能绘制出来的，而不是对应到平台的一个具体控件实现。我们所用的所有Swing控件都是直接或者间接用Graphics绘制出来的，这种实现方式最大的好处是很灵活，我们想要什么样的控件，就直接用Graphics绘制出来就是了。
Sun之所以用这种方式来实现，是为了在不牺牲移植性的基础上加入丰富的界面交互功能。
但是缺点也很明显：Swing的速度和效率是所有GUI系统中最慢的。
JBuilder和NetBeans的IDE都是纯正的Swing界面，启动一下，然后操作一下，比如拖动窗口之类的试试，你就会明白我在说什么。
之所以导致这个结果，其原因是：
1、Swing的类层次太深，一个JFrame经过了4层的类继承关系，如果再加上虚拟机的图形功能内部实现，就有6层的转接关系，每一次的继承和转接都会消耗系统资源和速度损失。（过多的继承会降低系统的速度，因为操作子类往往是使用基类指向来完成通用操作的）
2、Swing是基于自绘制图形技术的，而Java为了保持可移植性，所以无法使用硬件加速和平台特性来加快图形操作的速度。因而Java的图形技术都是“高层”的图形技术，就好像我们用Windows GDI去做动画一样，当然速度会很慢。
三、新的曙光－SWT
应该说，稍有阅历的Java的程序员都知道很多人对Swing效率低下的抱怨。IBM赞助的Eclipse开放源码项目，搞了一个另类的GUI系统－SWT。
SWT是一个非常独特的技术，其核心思想和Windows上的DirectX如出一辙，也许SWT的程序员真的是借鉴了DirectX成功的秘诀。
下面是SWT技术原理的类关系图：
我们会看见，SWT的类关系非常直接而且易懂，有点像Delphi的API接口思想（此是我随便乱弹，与Delphi没有什么关系）。最重要的一点就是SWT的核心思想：SWT的功能实现是完全构筑在以JNI为基础的，对运行平台的直接调用封装上的。
我们可以从图中看见，SWT的功能没有通过任何Java虚拟机来操作，而是直接调用Windows GDI和Shell功能，这一点是通过JNI方法调用完成。
一定会有人说SWT破坏了java的移植思想，不过Eclipse的大范围流行，正好证明了SWT非但没有阻碍移植性，反而提高了各种操作系统对于Java GUI的利用和期待。这不能不说Eclipse项目组是充满智慧的。
在Eclipse下，plugin目录的swt目录下，你可以发现一个dll动态库文件，这个dll就是JNI方法调用库。
基于SWT技术实现的Eclipse界面不但速度很快，效率很高，而且比Swing要美观的多。这就是直接调用封装的效果。
我们看看SWT的源代码就能更加明白为什么SWT那么流行，为什么SWT的速度像飞一样快，下面是从button类中抽取的一小段代码：
代码：
--------------------------------------------------------------------------------
int callWindowProc (int msg, int wParam, int lParam) {
if (handle == 0) return 0;
return OS.CallWindowProc (ButtonProc, handle, msg, wParam, lParam);
}
int windowProc () {
return ButtonProc;
}
LRESULT wmDrawChild (int wParam, int lParam) {
if ((style & SWT.ARROW) == 0) return super.wmDrawChild (wParam, lParam);
DRAWITEMSTRUCT struct = new DRAWITEMSTRUCT ();
OS.MoveMemory (struct, lParam, DRAWITEMSTRUCT.sizeof);
int uState = OS.DFCS_SCROLLLEFT;
switch (style & (SWT.UP | SWT.DOWN | SWT.LEFT | SWT.RIGHT)) {
case SWT.UP: uState = OS.DFCS_SCROLLUP; break;
case SWT.DOWN: uState = OS.DFCS_SCROLLDOWN; break;
case SWT.LEFT: uState = OS.DFCS_SCROLLLEFT; break;
case SWT.RIGHT: uState = OS.DFCS_SCROLLRIGHT; break;
}
if (!getEnabled ()) uState |= OS.DFCS_INACTIVE;
if ((style & SWT.FLAT) == SWT.FLAT) uState |= OS.DFCS_FLAT;
if ((struct.itemState & OS.ODS_SELECTED) != 0) uState |= OS.DFCS_PUSHED;
RECT rect = new RECT ();
OS.SetRect (rect, struct.left, struct.top, struct.right, struct.bottom);
OS.DrawFrameControl (struct.hDC, rect, OS.DFC_SCROLL, uState);
return null;
}
我想任何一个有点Windows编程知识的人都会惊讶SWT的方式和做法，LRESULT、WindowProc都是做什么的，我想不用我多说了。我第一次看见SWT的代码时，惊讶的张大了嘴，我实在无法想象SWT项目组敢于将Java技术与Windows平台结合到如此紧密（当然，Linux平台版本也同样的结合紧密）。我居然在SWT里发现了一个叫Tray的类，猜猜看它是干什么的？Tray可以让你在java程序中显示一个任务栏图标，极度晕眩！
我想，不用再继续介绍SWT了，你一定也很兴奋，从SWT开始，JavaGUI并不一定意味着缓慢、低效率、弱小的功能，Windows程序的眩目与速度，Java程序也可以拥有，这就是SWT的价值。
更加重要的是，SWT打破了长久以来人们对于移植性的误区，似乎移植性就只能使用少到可怜的功能，我们也可以用JNI来拥抱Java的世界，我想，将来不仅仅是界面会借助JNI的方式，也许我们的很多Java思想都会悄悄的发生改变，也许有一天我们的Java代码可以运行的像VB一样快，这种思想意识的变革就是SWT的价值。
至于Swing的结局，我不知道，但是我知道我更加喜欢轻量级的而且快速的SWT，给你的程序多一个选择吧。