要了解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组件的一个概述，更具体的应用需要在不断的实践中去体会。
【编辑推荐】
