AWT和Swing的概述

核心提示：java基本类 Java基本类 (JFC)，由一些软件包组成，AWT和Swing的概述，这些软件包主要包括下面一些应用程序接口(API): •抽象窗口工具集(AWT)(1.1及以上版本)， •Swing构件， 好了，这是对AWT和Swing的一个概述， •Java2D应用程序接口(2

　　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的一个概述，更具体的应用需要在不断的实践中去体会。