SWING与AWT

       这是刚开始学习SWING组件时在网上查的.现在已经学完了,并且还做了小工程(网吧计费管理系统&&固定资产管理系统).现在有空了,就好好整理下自己学过的东东.

 

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的一个概述，更具体的应用需要在不

断的实践中去体会。
　　
请记住本文永久地址:
http://www.javaresource.org/swing-awt/swing-awt-75484.html
或AWT和Swing的概述