swt 与 awt/swing 的区别与综合比较

本文通过对 Eclipse 的 SWT 和 Java Swing、Abstract Windows Toolkit（AWT）GUI 工具包进行比较，可以帮助新应用程序的开发人员从中选择适当的工具。


综合网上各家所述 集结此文:


是Swing是纯Java实现，而SWT和AWT是Java和JNI的混合。当然，它们的目标都是相同的，提供一个跨平台的APIs。然而为了达到这一点，SWT和AWT不得不牺牲一些组件和特性以提供一个通用的APIs。
AWT

一个AWT组件通常是一个包含了对等体接口类型引用的组件类。这个引用指向本地对等体实现。举java.awt.Label为例，它的对等体接口是LabelPeer。LabelPeer是平台无关的。在不同平台上，AWT提供不同的对等体类来实现LabelPeer。在Windows上，对等体类是WlabelPeer，它调用JNI来实现label的功能。这些JNI方法用C或C++编写。它们关联一个本地的label，真正的行为都在这里发生。作为整体，AWT组件由AWT组件类和AWT对等体提供了一个全局公用的API给应用程序使用。一个组件类和它的对等体接口是平台无关的。底层的对等体类和JNI代码是平台相关的。

SWT

SWT也使用JNI的方法论来实现。但细节不同于AWT。SWT的拥护者听到人们拿SWT和AWT相提并论可是会很生气的，Steve Northover，SWT之父，就曾为此抱怨过。

没错，它们是不同的。让我们深究SWT的代码。在SWT中，各个平台上唯一相同的部分是组件的接口，是类和方法的定义签名。所有的底层代码都是平台差异的。SWT为每个平台提供了OS类。这个类用JNI封装了许多本地APIs。SWT组件类通过把这些JNI方法黏合在一起提供一个有意义的功能。
例如，在Windows上，文本域的选择是由一个系统调用处理的。这个系统调用在Windows的OS类中作为一个本地方法实现。所以在Windows平台的Text的setSelection方法中只用到了一个JNI调用。

然而，在motif上，文本域的选择包含两个本地调用。SWT就在motif的OS类中实现了两个调用。所以在motif上组件类需要作两次调用来实现文本的选择。
现在你应该能看出SWT和AWT的最大不同了，它们使用了不同的对等体编程方式来消除平台差异。SWT用java代码或有JNI实现的java对等体来黏合系统调用。而AWT把代码包含在对等体中，使情况复杂化了，我个人觉得SWT的方法更加明智。[是否我翻译有问题，因为我并不觉得是这样更明智，SWT的无则模拟是不必要的，这是使用者才去做的事，SWT作为提供者应该无则C++实现，当然实现的是最核心的高度复用的又或者需要极大性能支持的，毕竟带了动态链接库，索性多放点东西。


Swing

到了Swing这里，一切就变得清晰和直接了。除了顶层容器，Swing的实现不依赖于具体平台。它掌管了所有的控制和资源。Swing所需要的是事件输入来驱动系统，以及承接自顶层AWT容器的图形处理，字体和颜色。普通的Swing组件可以看作是AWT容器的一块逻辑区域。它们并没有注册对等体。所有添加到同一顶层容器的Swing组件共享它的AWT对等体以获取系统资源，如字体，图形处理等。Swing将组件自己的数据结构存储在JVM的空间中。它完全由自己管理画图处理，事件分发和组件布局

资源管理

由于AWT和SWT都持有对本地组件的引用，它们必须以正确的方式释放这些引用以避免内存泄露和JVM崩溃。AWT将绝大多数资源管理任务交给系统，将开发者从单调乏味的资源管理中解救出来。然而这使得AWT的实现复杂化了。一旦它实现了，开发者很少有机会犯错误并使他们的程序崩溃。

SWT用的是另一种方法。大体上，SWT让开发者自己来管理资源。它的一条著名的规则是：谁创建，谁释放。因此开发者必须谨慎地显式调用dispose方法释放每一个由他创建的组件和资源。这简化了SWT的实现模型，但把开发者摆在了因错误编码而易于造成程序崩溃这一风险之上。

模拟方式的区别

Swing和SWT在它们的实现上都使用了模拟。SWT只模拟平台上缺失的组件。区别是SWT的模拟更像是AWT的Canvas实现的模拟。SWT的Composite类有它自己在操作系统中相应的对等体。它从自己的对等体中获得所有它所需要的资源如图形处理的对象，字体和颜色等。它直接从操作系统获取所有的事件并进行处理。然而，Swing组件在操作系统中没有相应的对等体。它只是一块顶层容器中的逻辑区域，实际上它从顶层容器的对等体中借用资源。Swing的事件并不是底层系统产生的事件。它们实际是由顶层容器处理AWT事件所产生的伪事件。我们会在稍后的事件部分中详细介绍它。

图形层结构

另一个不同之处是Swing组件的z-order系统是来自于AWT组件的。如上所述，Swing组件与顶层AWT容器共享一个对等体。因此，Swing组件也和顶层容器有相同的z-order。SWT和AWT组件都有不同于顶层容器的z-order，通常是高于顶层容器。故而如果AWT组件和Swing组件混合在一起的话，Swing组件将可能被AWT组件遮住。当操作系统开始更新UI的时候，顶层容器和Swing组件总是先于AWT组件绘制。当它们完成绘制，AWT组件会覆盖Swing可能绘制过的地方。因此不提倡Swing和AWT组件的混用。如果有一个浮动的Swing组件如菜单，AWT组件很可能遮盖菜单。
布局管理器
并不是三者中的所有部分都是不同的。布局管理器是一个例外。开发GUI应用程序，当容器改变大小的时候，组件需要重定位或改变大小。在传统的编程语言中，这依靠监听大小改变的事件来实现。相应的片段散落在源代码的各个角落降低了程序的可读性。Java引入了将布局代码封装的思路，称之为布局管理器。当布局管理器对象被设置到一个容器中，它自动处理大小改变的事件。当大小改变时，管理器的布局方法被调用以重定位子组件或调整它们的形状。

AWT，SWT和Swing都以这样的方式来组织，而都有它们各种独特的布局管理器。由于AWT和Swing拥有一个共同的超类java.awt.Component，它们的布局管理器可以交替地使用。





Java性能、Swing和SWT的比较、Swing方面的一些技术。
=====================================================

         总的来说Swing/AWT和SWT在事件处理机制上是类似的，窗口组件的树状结构也是类似的。图形用户界面系统在事件处理设计上有两大类，一类是单线程模型，一类是多线程模型。在事件处理机制上，三者都是遵循单线程规则。

         单线成模型对于事件处理不保证线程安全性(Thread Safety)，所有的事件处理都在Event Dispatch Thread(EDT)上进行，此一类事件模型通常叫做单线程模型。这种模型规定所有对组件的访问操作必须在EDT上完成。为什么对于组件的访问需要在EDT上完成？这主要是为了保证对于组件状态的改变是同步的，保证了界面组件的可确定性。这中模型是大部分图形用户界面工具采用的模型，包括Swing/AWT、SWT、GTK、WinForm等等。

         这种模型的好处是，结构设计和代码实现都比较简单，避免了为了实现线程同步的复杂处理。但是也带来了一些问题，最常见的问题是，程序员容易将长时间复杂任务的处理放在事件处理函数完成，造成EDT线程被阻塞，给用户造成界面失去响应的错觉。其实人们对于Swing速度慢和反映迟钝的感觉大部分来源于此，简单的说，是程序员的问题，而不是Swing自身的问题，是因为程序员没有理解这种事件处理机制造成的。其实在SWT、GTK、WinForm等任何以这种事件模型为基础的工具都会出现。重现的方法就是你简单的将长时间处理的任务放在事件处理函数中，你的用户界面就会失去响应。

         如何解决这种问题？通用的办法就是采用异步线程处理长时间任务。但是还要记住的是，在这种任务中对于界面的更新要采用SwingUtilities.invokeLater或者在SWT采用Synchronize方法，将访问操作放到EDT上进行。关于如何写一个有效处理长时间任务的Swing程序，将会在其他文章中描述。

         多线程模型中，所有的事件处理都是在异步线程中进行，界面组件同步访问的操作需要程序员来保证。这种模型设计本身很复杂，而且对于程序员来说要求比较高，必须对线程同步编程很熟悉，而且花在同步上的操作影响了平台的性能。一般现在的图形界面工具都不再采用这种方式。

         下面比较一下Swing/AWT/SWT在API、GUI特征以及实现方法的不同。

         在API上，Swing和AWT是兼容的，SWT是单独的一套接口。

1.Swing/AWT的组件在生成时可以脱离父组件独立存在，SWT必须有父组件存在。这主要是由于SWT的资源是自己管理，SWT程序必须负责释放不用的资源，为了避免这种释放资源的重复性，SWT父组件被设计成在析构时自动递归调用子组件的析构函数。

2.Swing/AWT的资源回收由垃圾收集器负责，SWT必须由SWT程序显式释放。

3.Swing/AWT的事件线程循环不需要程序员显式启动，SWT必须要程序员来显式启动。

         Swing/AWT和SWT在布局管理器上是类似的，没有太大区别。

         在GUI特征上，有两个比较层面，一个是组件种类，一个是组件本身特征。在理解这些特征时，一定要牢牢记住这样一个准则：Java是平台无关的语言，因此它对应用程序所提供的API一定要各个平台都相同，GUI特征其实也是API，所以GUI的特征必须在各个平台都相同。

         组件类型上，AWT采用的是最大公约数方法，而Swing/SWT采用的是最小公倍数方法。简单的说AWT是各个平台所有组件集合的交集，而Swing和SWT则是各个平台组件的并集。下图所示，假设操作系统平台OS1上提供组件{C1, C2, C3, C4, C7}，而OS2提供{C1, C2,C3, C4, C6}，OS3提供{C1, C2, C3, C4, C5}，那么其中的阴影部分就是AWT所实现的组件，由于C5、C6和C7是各个平台所特有的，因此AWT中就不包含这些组件。比如Table和Tree在Java支持某些操作系统平台中不包含，所以在AWT中就没有Table和Tree。由于AWT的组件太贫乏，所以AWT在现在复杂应用程序几乎没有什么用。Swing和SWT提供的组件是各平台所有组件的并集，这样就解决AWT的组件贫乏的缺陷。也就是说，Swing和SWT提供的组件包括C1到C7的所有组件，而AWT只提供C1到C4的所有组件。



         从组件本身的特征来看，SWT和AWT采用了相同的策略，即最大公约数，而Swing采用的是最小公倍数。如下图所示，假设对于同一个组件C，如果它在OS1上提供的特征包括{a,b,c,d,e}，而OS2上提供的特征包括{a,b,c}，而OS3包括的特征有{a,b,c,d}，那么SWT和AWT提供的组件特征只包括{a,b,c}，而Swing的包含的平台特征包括{a, b, c, d, e}。比如由于Solaris平台上的按钮不提供对于图标的支持，所以SWT和AWT的独立按钮就不提供对于按钮图标的支持，而Swing提供按钮图标的支持。



         在实现方法上，AWT采用Java+Native C Peer(一种JNI调用）方法，SWT根据各平台的不同情况，一部分组件使用Java+Java Peer+JNI Wrapper，一部分采用Java模拟的方法，而Swing则采用所有组件都纯粹Java模拟的方法。
                    AWT的接口和各操作系统组件之间的差别采用Native C Peer实现的方法来填平，下面是它的结构示意图：


           其中AWT Native Peer Impl部分都是C语言写的，在各种操作系统上是不同的，但是它们和AWT Component组件之间的AWT-Peer JNI调用接口是不变的，AWT Component的Java代码实现在各个平台上都是相同的，最后AWT Component向Application提供同一的API接口。

           SWT同AWT不同，它在Native Component上进行了一层薄薄的JNI封装，所有操作系统的API调用都被映射到一个JNI调用上，然后SWT通过Java代码组合这些JNI调用实现同一的API，下面是其结构示意图：



         因此SWT的Java代码实现部分在各个平台是不同的，它的C代码部分即JNI Wrapper部分只是一个各平台GUI API的JNI简单映射，SWT通过Java Peer在各平台的不同实现填平了各平台差异，从而给Application提供同一的API接口。当然SWT对于某种平台上缺少的组件采用的方法和Swing基本类似。

         Swing和上两中方式完全不同，它直接调用Java2D，抛弃了本地操作系统平台组件的实现，完全自己画出来了整个组件，当然Java2D底层也是调用平台的图形系统。下面是它的示意图：



         当然Swing是建立在AWT基础上的，对于一些顶层容器类如Frame / Dialog / Window以及Applet是直接采用AWT的，这儿为了方便并没有画出。由于Java2D API是个平台无关的，因此Swing的Java实现代码在个平台都是一样的，都是一套，当然除了与Swing的Look And Feel相关的东西以外。






关于AWT和Swing的一点讨论

目前大多数的嵌入式Java虚拟机都提供了对AWT 的支持但是不提供对Swing 的支持。但是，在标准版的Java平台上Swing 才是推荐使用的图形界面系统，在Sun 公司所提供的Java Tutorial 中甚至把基于AWT 的图形用户界面设计这一部份从其网站中删除，需要利用到AWT 进行图形用户界面设计的用户只有将该部份下载到本地硬盘才能够使用这部份教程。在标准版Java中正值春风得意的Swing 为什么到了嵌入式应用中便不再吃香了呢？

AWT 是Abstract Window ToolKit (抽象窗口工具包)的缩写，这个工具包提供了一套与本地图形界面进行交互的接口。AWT 中的图形函数与操作系统所提供的图形函数之间有着一一对应的关系，我们把它称为peers。 也就是说，当我们利用 AWT 来构件图形用户界面的时候，我们实际上是在利用操作系统所提供的图形库。由于不同操作系统的图形库所提供的功能是不一样的，在一个平台上存在的功能在另外一个平台上则可能不存在。为了实现Java语言所宣称的"一次编译，到处运行"的概念，AWT 不得不通过牺牲功能来实现其平台无关性，也就是说，AWT 所提供的图形功能是各种通用型操作系统所提供的图形功能的交集。由于AWT 是依靠本地方法来实现其功能的，我们通常把AWT控件称为重量级控件。

Swing 是在AWT的基础上构建的一套新的图形界面系统，它提供了AWT 所能够提供的所有功能，并且用纯粹的Java代码对AWT 的功能进行了大幅度的扩充。例如说并不是所有的操作系统都提供了对树形控件的支持， Swing 利用了AWT 中所提供的基本作图方法对树形控件进行模拟。由于 Swing 控件是用100%的Java代码来实现的，因此在一个平台上设计的树形控件可以在其他平台上使用。由于在Swing 中没有使用本地方法来实现图形功能，我们通常把Swing控件称为轻量级控件。

说到这里我想各位读者应该明白了AWT和Swing之间的基本区别：AWT 是基于本地方法的C/C++程序，其运行速度比较快；Swing是基于AWT 的Java程序，其运行速度比较慢。对于一个嵌入式应用来说，目标平台的硬件资源往往非常有限，而应用程序的运行速度又是项目中至关重要的因素。在这种矛盾的情况下，简单而高效的AWT 当然成了嵌入式Java的第一选择。而在普通的基于PC或者是工作站的标准Java应用中，硬件资源对应用程序所造成的限制往往不是项目中的关键因素，所以在标准版的Java中则提倡使用Swing， 也就是通过牺牲速度来实现应用程序的功能。

抽象窗口工具集
        　　在开发applet和图形应用程序时，一般需要用到AWT，AWT是免费Java开发工具包(JDK)的一部分。
        AWT的作用是给用户提供基本的界面构件，例如按钮、列表、菜单、文本域等等。AMT
        构件主要是用来建立图形用户界面的独立平台。此外，AWT还提供事件处理结构、支持剪贴板、数据传输和图像操作。随着2D
        API的出现，AWT还包括提供高级字体操作、打印、地理数据获取和输入方法等功能的软件包。AWT的初始版本是基于在简单用户界面中开发小applet程序而设计的，与之相比，当前的AWT做了很大的改进，它提供事件模型重新设计、剪贴板和数据传输支持以及打印和无鼠标操作等功能。从而与Parc
        Place的VisualWork或Borland公司的Object Windows Library(OWL)等企业级用户界面具有更多的可比性。
        　　
        　　同位体和平台独立
        　　随着Applet程序和图形应用程序接口的发展，AWT提供了一系列的通用类，这些通用类在引用时不需要考虑特定的窗口平台，同位体(Peer)就属于这种AWT类集。同位体是一种本地图形用户接口(GUI)构件，由AWT类管理。同位体的工作方法和它们对程序开发的影响常

        　　常让人混淆。
        　　AWT构件中，包含有对其同位体的大量实用操作。例如，如果你使用AWT创建一个menu类的实例，那么当Java运行时系统将创建一个菜单同位体的实例，而由创建的同位体实际执行菜单的显示和管理。在创建菜单实例中，Solaris
        JDK将产生一个Motif菜单同位体;Windows 95将产生一个Windows 95菜单同位体;Macintosh
        JDK将产生一个Macintosh菜单同位体等等。
        　　
        　　一个Java程序创建并显示AWT构件，AWT构件创建并显示本地构件(同位体)。AWT开发组决定使用同位体方法，这一方法使得交叉平台窗口工具开发变得极为迅速。
        使用同位体可以避免重新实现本地窗口构件中已包含的实用工具，而且，使用同位体还能使applet和应用程序保留在本地系统中，这是因为同位体实质上是由本地构件组成的，而AWT类仅仅是同位体外围的包装与操作工具。

        　　虽然在使用AWT时，很少需要直接处理同位体，但它们的存在却影响其操作结果。例如，如果没有同位体，则某些java.awt.Component方法不会象我们所预期的那样进行工作。使用同位体方法可以在记录时间内实现GUI工具构件。然而，使用同位体也有很多的缺点，同位体设计基础存在缺陷并且不能缩放。

        　　
        　　轻量构件
        　　AWT构件全都是重量构件，即它们都具有同位体，并且在本地
        (不透明)窗口中进行显示。这样使用将花费昂贵的代价，而且在更改其默认行为时，不可以将其派生为子类。此外，它们必须是矩形的，而且不能有透明的背景。同位体可以快速产生一个GUI工具构件。因为本地同位体做了更多的实际工作，而AWT

        　　类所做的仅仅是表面工作，因此，它很容易开发。开发最初的AWT，只用了不到6个星期的时间。但这种效率带的利益在很大程度上被一些不利因素抵销了，比如基本的同位体结构、有限的事件模式以及同位体与AWT之间不匹配造成的大量缺陷。

        　　1.1版本的AWT引人了轻量构件的概念。轻量构件直接扩展了java.awt.Component或java.awt.Container。轻量构件没有同位体，在其重量容器窗口中显示，而不是在其本身窗口中显示。轻量构件不会导致与它们自己关连的不透明窗口的性能损失，而且还可以有透明的背景。其中有透明背景的性能意味着即使轻量构件的界限域实际上是矩形的，它也可以显示为非矩形。

        　　
        　　SWing的历史
        　　要了解Swing，首先必须了解AWT,AWT是Swing的基础。
        　　Java的发展速度超出了人们的想象，Java
        API中最可视的部分----AWT突然成为了人们关注的焦点。遗憾的是，原来的AWT不能满足发展的需要。
        　　原来的AWT不是为许多开发人员使用的、功能强大的用户界面
        (UI)工具包而设计的，其设计目的是支持开发小应用程序中的简单用户界面。例如，原来的AWT缺少许多面向对象UI工具包中所能见到的特性，例如，剪贴板、打印支持和键盘导航等特性在AWT中都不存在。原来的AWT甚至不包括弹出式菜单或滚动窗格等基本特性，而弹出式菜单和滚动窗格是开发现代用户界面的两个基本元素。

        　　此外，AWT的下层构件还有严重的缺陷。人们使AWT适应基于继承的、具有很大伸缩性的事件模型。甚至更糟，基于对等组件
        (peer)的体系结构也被用于AWT，该体系结构注定要成为AWT的致命弱点。
        　　为了尽快推向市场和保持本地的界面样式，于是产生了基于对等组件的体系结构，而该体系结构注定是要失败的。对等组件是完成薄弱的AWT对象所委托任务的本地用户界面组件。

        　　对等组件负责完成所有的具体工作，包括绘制自己、对事件做出反应等，这使得AWT组件除了在适当的时间与其对等组件交互外无事可做。由于AWT类只是较复杂的本地对等组件的外壳，所以，AWT的早期开发人员能在最快的时间内创建组件。例如，java.awt.Panel类只包含十二行代码。

        　　另外，对等组件的设计也有严重的缺点。首先，在大多数平台上，对等组件都是在本地窗口中绘制的。每个组件一个本地窗口实在不能得到高性能，为此，含有大量AWT组件的小应用程序付出了很高的性能代价。

        　　把不同平台上的本地对等组件硬塞进Java框架中也是一个问题，使这些AWT组件跨平台的表现一致是完全不可能的。结果，不但没有实现急需的新组件，而且开发时间都浪费在修补对等组件的错误上和不兼容问题上了。

        　　更糟的是，AWT有很高的错误发生率。于是，第三方开始提供他们自己的工具包，这些工具包提供了更可靠的下层构件并提供了比AWT更多的功能。这些工具包之一是Netscape的Internet基础类
        (IFC)，IFC是一组建立在NEXTSTEP中的用户界面工具包概念基础上的一组轻量类。IFC组件不是对等的，在许多方面胜过了AWT组件。IFC还吸引了更多的开发人员加盟。

        　　由于认识到Java领域很可能在标准用户界面工具包问题上出现分裂局面，JavaSoft和Netscape达成了一个交易，共同实现Java基础类
        (Apple公司和IBM公司也参加了JFC的开发)。Netscape开发人员与Swing工程师一起合作，以便把大部分的IFC的功能嵌人到Swing组件中。

        　　起初打算让Swing类似于Netscape的IFC。然而，随着时间的推移，在增加了插入式界面样式等特性并修改了设计之后，Swing大大地偏离了它原来的目标。随着Swing1.1版本的推出，虽然大量的IFC技术仍然嵌在Swing中，但是，Swing与IFC相似的部分已大部分消失了。今天，在一个功能全面的用户界面工具包中，Swing提供了AWT和IFC中最优秀的成份。

        　　
        　　轻量组件与重量组件的比较
        　　轻量组件首次出现在AWT1.1版本中。AWT最初只包括与本地对等组件相关联的重量组件，这些组件在它们自己的本地不透明窗口中绘制。
        　　相反，轻量组件没有本地对等组件，而且在它们的重量容器的窗口中绘制。
        　　由于轻量组件不在本地不透明的窗口中绘制，因此，它们可以有透明的背景。透明的背景使显示的轻量组件可以是非矩形的，虽然所有组件
        (重量的或轻量的)都基于一个矩形边框。
        　　Swing组件几乎都是轻量组件，那些顶层容器:窗体、小应用程序、窗口和对话框除外。
        　　因为轻量组件是在其容器的窗口中绘制的，而不是在自己的窗口中绘制的，所以轻量组件最终必须包含在一个重量容器中。因此，Swing的窗体、小应用程序、窗口和对话框都必须是重量组件，以便提供一个可以在其中绘制Swing轻量组件的窗口。

        　　
        　　好了，这是对AWT和Swing的一个概述，更具体的应用需要在不断的实践中去体会。

SWT

SWT在性能和外观上、以及易用性上比起Swing来说确实要好得多。但是SWT的致命缺点在于：与平台绑定过紧，跨平台发布的时候比Swing要麻烦得多。 swt有个缺点：必需使用本地动态库.    SWING可以不考虑这点.


SWT 、AWT 和 Swing 特性的比较
功能/角色/外表 AWT Swing SWT（风格）
显示静态文本 Label JLabel Label, CLabel
显示多行静态文本 Multiple Labels 具有 HTML 内容的 Multiple JLabels 或 JLabel 具有新行的 Multiple Labels 或 Label
显示多行格式化静态文本 具有不同字体的 Multiple Labels 具有 HTML 内容的 JLabel 具有不同字体的 Multiple Labels
单行文本输入 TextField JTextField Text(SWT.SINGLE)
多行文本输入 TextArea JTextArea Text(SWT.MULTI)
显示图像 N/A JLabel Label
显示文本和图像 N/A JLabel CLabel
提示弹出帮助 N/A 组件的 setToolTip，JToolTip 子类 控件的 setToolTip
风格化的文本输入 N/A JEditorPane StyledText
从条目列表中进行选择 List JList List
简单按下具有文本的按钮 Button JButton Button(SWT.PUSH)
简单按下具有文本或图像的按钮 N/A JButton Button(SWT.PUSH)
绘图区域；可能用于定制控件 Canvas JPanel Canvas
选中/取消复选框 CheckBox JCheckBox Button(SWT.CHECK)
单选按钮选择 CheckBoxGroup ButtonGroup 和 Menu Group 和 Menu
从一个下拉列表中选择 Choice JComboBox Combo、CCombo
输入文本或从下拉列表中选择 N/A JComboBox Combo、CCombo
可滚动区域 ScrollPane JScrollPane 创建 Scrollable 子类
顶层窗口 Dialog、Frame、Window JDialog、JFrame、JWindow 具有不同风格的 Shell
通用窗口 Window JWindow Shell
框架窗口 Frame JFrame Shell(SWT.SHELL_TRIM)
对话框窗口 Dialog JDialog Shell(SWT.DIALOG_TRIM)
菜单 Menu JMenu Menu
MenuItem MenuItem JMenuItem MenuItem
菜单快捷键 通用击键 与 AWT 相同 依赖于主机的快捷键
弹出菜单 PopupMenu JPopupMenu Menu(SWT.POPUP)
菜单条 MenuBar JMenuBar Menu(SWT.BAR)
显示插入符号 N/A Caret Caret
Web 浏览器 N/A JTextPane（HTML 3.2） Browser（通过嵌入式浏览器）
Web 页面中的嵌入式控件 Applet JApplet 主机控件（例如 OLE）
其他控件的通用容器 Panel JPanel Composite
其他控件的有边界通用容器 Panel（如果是手工画的） 具有 Border 的 JPanel Composite(SWT.BORDER)
其他控件的有边界和标题的通用容器 N/A 具有 TitledBorder 的 JPanel Group
单选按钮（一个被选中） Checkbox JRadioButton Button(SWT.RADIO)
单选按钮的控件扩充 CheckboxGroup RadioButtonGroup Group
箭头按钮 N/A 具有图像的 JButton Button(SWT.ARROW)
支持文本显示方向 通过 ComponentOrientation 与 AWT 相同 很多组件都可以支持这种风格
焦点切换 Policy 和 Manager 对象 与 AWT 相同 下一个控件
定制对话框 Dialog 子类 JDialog 子类 Dialog 子类
访问系统事件 EventQueue 服务 与 AWT 相同 Display 服务（不如 AWT 健壮）
系统访问对话框 FileDialog JColorChooser、JFileChooser ColorDialog、DirectoryDialog、FileDialog、FontDialog、PrintDialog
显示简单消息对话框 N/A（必须是 Dialog 子类） JOptionPane 静态方法 具有很多风格的 MessageBox
显示简单提示对话框 N/A（必须是 Dialog 子类） JOptionPane 静态方法 N/A（JFace 中用来实现这种功能的子类）
布局管理器 BorderLayout、CardLayout、FlowLayout、GridLayout、GridBagLayout AWT 加上 BoxLayout、CenterLayout、SpringLayout FillLayout、FormLayout、GridLayout、RowLayout、StackLayout
基本的绘图控件 Canvas JPanel Canvas
基本绘图 Graphics 和 Graphics2D 对象 —— 基本形状和文本，任意 Shapes 和 Strokes、Bezier 以及文件 与 AWT 相同 GC 对象 —— 基本形状和文本
绘图转换 Affine，合成 与 AWT 相同 N/A
离屏绘图（Off screen drawing） BufferedImage、drawImage 与 AWT 相同 Image、drawImage
双缓冲区 手工 自动或手工 除非由主机控件提供，否则就是手工
打印 PrintJob 和 PrintGraphics 与 AWT 相同 向 Printer 设备绘图
定制颜色 Color 与 AWT 相同 Color
定制字体 Font、FontMetrics 与 AWT 相同 Font
光标选择 Cursor 与 AWT 相同 Cursor
图像特性 从文件中加载，动态创建，可扩充地编辑 与 AWT 相同 从文件中加载，动态创建，基本编辑
输入自动化 Robot 与 AWT 相同 N/A
显示工具条 N/A JToolBar ToolBar、CoolBar
显示进度条 N/A JProgressBar ProgressBar
将空间划分成区域 N/A JSplitPane Sash 或 SashForm
显示一个分标签页的区域 N/A JTabbedPane TabFolder、CTabFolder
显示制表信息 N/A JTable Table
格式化表的列 N/A TableColumn TableColumn
显示层次化信息 N/A JTree Tree
从一定范围的值中进行选择 N/A JSlider Slider
从一组离散范围的值中进行选择 N/A JSpinner Scale
对于基本显示的访问 Toolkit、GraphicsConfiguration、GraphicsDevice 与 AWT 相同 Display
将条目添加到系统托盘（system tray）中 N/A N/A Tray
关键：N/A —— 不适用。在很多情况中，这种特性都可以通过创建定制控件或控件容器或利用其他定制编程来实现，不过实现的难度会有所不同。

该表原文地址 http://blog.sina.com.cn/s/blog_55fc875c0100dhd1.html