AWT/Swing与SWT/JFace的区别

 Java基本类
Java基本类 (JFC)，由一些软件包组成。这些软件包主要包括下面一些应用程序接口(API):
•抽象窗口工具集(AWT)(1.1及以上版本)。
•Swing构件。
•Java2D应用程序接口(2D API)。
•兼容程序接口。
上面列出的这些应用程序接口可能会出现在多个软件包中。例如:2D API在Java.awt和 Java.awt.image软件包中都存在，虽然像Java.awt.geom等一些特殊的软件包也支持2D API，但 是大量的2D API类都存在于Java.awt软件包中。

AWT(1.1及以上版本)是JFC的核心。AWT为JFC的构成提供了以下的基本结构:
•代理事件模型。
•轻量构件。
•剪贴板和数据传输。
•打印和无鼠标操作。

抽象窗口工具集
在开发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 是一个库，它创建了Java 版的本地主机操作系统 GUI 控件。它依赖于本机实现。这意味着基于 SWT 的应用程序具有以下几个关键特性：


它们的外观、行为和执行类似于“本机”应用程序。
所提供的窗口小部件（widget）反映了主机操作系统上提供的窗口小部件（组件和控件）。
主机 GUI 库的任何特殊行为都在 SWT GUI 中得到反映。
这些目标使得 SWT 不同于 Java 技术的 Swing，Swing 的设计目标是消除操作系统的差异。

SWT 库反映了主机操作系统的基本窗口小部件。在许多环境下，这种方法太低级。JFace 库有助于向 SWT 应用程序中添加大量服务。JFace 并没有隐藏 SWT，它只是扩展了 SWT。正如您将在这一系列的后面部分中看到的，SWT 最重要的扩展之一是，将应用程序的数据模型与显示及更改它的 GUI 隔离开来。

 

 

       Swing和SWT是采用不同的机制的，AWT是Swing的前身，实际上是调用本地操作系统的控件。由于在不同的操作系统下，提供的控件是不一样的，AWT采用最小公约数的办法，只提供所有操作系统都有的控件。但后来SUN改变了做法，在Swing里除了JFrame,JWinodows,JDialog（记不太清了，好像是这几个）是调用本地操作系统的控件，其它JPanel,JButton之类的都是绘出来的，所以Swing在所有平台看起来都是一样的外观。这样保持了外观一致性，但牺牲了性能。

        IBM更喜欢AWT的实现机制，做出了SWT，SWT采用的是最大公倍数的做法。SWT大部分都是用的本地操作系统的控件，一些在ｗｉｎｄｏｗｓ里有的控件可能在ｌｉｎｕｘ下没有，对这种控件才采用自己绘制的方式。SWT采用类似JAVA虚拟机的方式，在不同的平台，有不同的开发包，我们写的ｊａｖａ代码是一样的，但不同平台下看起来外观是不一样的，但性能提升很高，据说和C++做的界面速度差不多：）
也许你会问哪种更好，引一名话：

  this is equivalent to asking whether a harmmer is better than a screw driver,of course ,a hammer wieldded with sufficient force can probably drive a screw into a wall ,and the butt of a screw can be used in a pinch to knock in a nail. However, a good carpenter keeps both harmer and screw drivers in her tool box and will use the tool that is appropriate for the job at hand.

        个人感觉以前ｊａｖａ做界面完全没有优势，从外观到性能（我很喜欢Swing的look and feel,可以改变风格），SWT的出现改变了性能上的缺点，再加上JFace，及Eclipse的RCP，我还是倾向于用SWT。

下面是网上流传的关于SWT来源的消息，引用一下：

        要想弄清楚为什么一切都被弄得如此混乱，要从几年前只存在AWT的时候说起。SUN当时已经建立了一套基本的可移植控件类，这些类映射到不同操作系统上的原生窗口组件（native widget），显然下一步应该继续增强这套模型，除了初始的CUA 92组件（文字、按钮等等），再继续加上表格、树、记事本、滑块等等……当时的AWT还满是漏洞，远不能称为可靠，还需要SUN的coder们去修补。SUN的developer们如Graham和Otto总是习惯于公开把他们的bug归咎为操作系统的差异，比如“Windows和OS/2的焦点次序不同”或者“在……之间Ctrl-X的行为不一样”，以及其他苍白的托辞，好让批评的火力从SUN太早释出代码这个问题的真相上移开。然后Amy Fowler来到了SUN。不是我大男子主义，Amy是个聪明的美女，大多数呆头呆脑只懂技术的开发人员都要被她捏在手里。

        Amy来自一家Smalltalk公司，叫做Objectshare，在那里她负责搞UI类库。跟Java相比Smalltalk的历史有些悲惨，曾几何时有3家庞大的Smalltalk公司——IBM、Parc-Place和Digitalk。在90年代初期3家公司的市场份额大致相等，生活是美好的。Parc-Place采用仿窗口部件（emulated widgets）的设计（即Swing的设计），IBM和Digitalk则采用原生窗口部件（native widgets）。后来IBM压倒了另外两家，因此他们打算合并成一家，假设叫做Parc-Place Digitalk。随后当他们试图将他们的产品融合到一个叫做Jigsaw的计划中时爆发了一场大战，计划由于政治原因失败了（开发人员实际上已经能让它运转起来），就因为原生和仿造两派的死战。Amy赢得了精神上的胜利，不过在IBM我们赢得了他们所有的生意，因为这两家公司在一整年里除了吵架什么都没做。当尘埃落定之后PPD（Parc-Place Digitalk当时已改名为Objectshare，跟Windscale改名为Sellafield的原因相同——让人们淡忘之前发生的灾难）的股票价格从60美元掉到了低于1美元1股。他们因为伪报收入被NASDAQ摘牌，从此消失。此时SUN正走上与PPD类似的技术方向，于是PDD的技术人员都把他们的简历投到了SUN。Amy被雇佣了，她承诺通过轻量级方案解决所有窗口组件的问题，因此说服SUN管理层让她当了GUI开发部门的头头。她是拿着“这里原来的人都搞砸了，我是来解决的”的钥匙进来的。随后Amy雇佣了所有她过去在Parc-Place的旧朋友，让他们来开发Swing。

        显然Swing应该做的是仅仅成为一个绘制框架，给那些希望创建地图软件或者绘图软件的人们使用，无论如何，应该围绕AWT类库来建造它，按钮之类的东西仍然交给AWT来管。SUN的人比如Philip和Mark已经让AWT能够处理表格、树和记事本（notebook，？），所以Swing的方向应该说很明显了。但那些毁了PDD的人不干，他们非要把一切都弄成轻量级的。由于SUN管理层的无知，再加上Amy无情的政治手段，造成了我们今天所见的混乱局面。Amy还使SUN相信Swing是作为Mozilla项目的一部分与Netscape联合开发的，事实上这只是她的宣传伎俩。

        在IBM，我们从第一天起就憎恶Swing。庞大、满是错误，而且难看至极。原先我们的工具如VisualAge for Java都是用Smalltalk（用的是原生窗口组件）写的，所以当我们将这些工具向Java代码库迁移时，我们需要一套窗口组件。IBM这边的开发人员都是原来搞Smalltalk的那一批人，我们对管理层要求用Swing来构建WebSphere Studio工具都非常不情愿。Swing是个可怕的充满缺陷的怪兽。在WebSphere Studio最初的预览中，当与Microsoft Visual Studio作对比演示的时候，我们所有的客户都讨厌它，就因为它的外观，而不管它的功能有多强。大多数消费者都不会买一辆让人觉得难看的车，哪怕这车有一台出色的引擎。因此我们开始了一个项目，是把我们的Smalltalk原生窗口组件移植到Java上去。这个项目是加拿大的Object Technology International小组做的。这个项目获得了成功，被运用在在我们发布的VisualAge Micro Edition产品中，VisualAge Micro Edition后来成为J2ME开发方面一个非常成功的IDE。但是OTI的人发现，Swing在读取Windows事件方面有极严重的缺陷，我们甚至无法进行SWT（S开始是Simple的缩写，不过后来变成了Standard的缩写）和Swing间的互操作。他们在读事件队列的时候用了一种可能留下内存漏洞的方式，所以我们不得不采用我们自己的查询Windows事件队列的循环，以纠正这个错误。我们试了一次又一次让SUN修复这个错误，但Amy就是听不进去，所以我们才决定SWT和AWT/Swing不能共存。我们甚至在SWT中定义了自己的Point和Rectangle类——整个工具包对AWT或Swing都没有任何依赖。我们把这个工具包放到了Eclipse中，这是一个工具平台，它的总体设计目标就是要战胜Micrsoft和Visual Studio。Eclipse是开源的，所以任何人都可以在上面构建自己的东西，我们已经有像TogetherSoft和Rational这样的公司移植到了上面。我们的竞争者是Microsoft，所以我们所有努力和注意力都是从正面针对Microsoft。

        不管怎么说SUN对此非常不满。他们的Netbeans跟Eclipse做的是相同的事，因此他们向IBM高层抱怨。他们认为SWT是要将你绑到Windows上，这纯粹是胡说，因为SWT能通过GTK在Mac/Linux上运行，以及一大堆嵌入式平台。他们拒绝让Eclipse获得Java认证，因为里面有原生代码，所以Eclipse产品必须很小心地使用单词“Java”这个SUN的商标。Eclipse甚至不能把自己称为一个Java IDE，SUN已经威胁过要采取法律行动来制止IBM在任何时候把Eclipse称作一个Java IDE。结果之一就是IBM在Eclipse上创建的GUI设计工具，允许你构建Swing/AWT GUI，却不让你往里面拖放SWT窗口控件。

        将SWT从Eclipse中分离出来是完全可能的，只需要把DLL抠出来放到路径中，并使用窗口组件工具包来给你的银行或者保险或者其他什么应用程序开发GUI。再次说明，我们无法更进一步，因为SUN把我们的双手绑上了。虽然作为Eclipse开放源码协议的一部分，CPL允许我们提供这样的解决方案，但SUN已经很清楚地表明他们不希望我们这样做。

        对于用户社区来说，无论IBM和SUN的最终动机是什么，我发现有一点总是很有趣：喜爱Swing的人总会说“一旦你花上几年时间去掌握它，你就能正确地使用它”，这基本上是他们在试图证明和维护他们辛苦得来的用途有限的专门技术；而SWT的拥护者们说的是“哇，这真快，这跟原生的一样，还可以用XP皮肤……它还又轻又小”。有一句话是我喜欢的，我们的一个用户说，Swing就像Java决定不通过操作系统来实现原生的IO，而是通过磁头马达API自己来读磁盘的扇区。Swing基本上就是这样的，它拿着个底层的“paint(Graphics)”方法，自己来绘制所有的窗口组件。