Java基本类 Java基本类 (JFC)由一些软件包组成这些软件包主要包括下面一些应用程序接口(API): ;抽象窗口工具集(AWT)(及以上版本) ;Swing构件 ;JavaD应用程序接口(D API) ;兼容程序接口 上面列出的这些应用程序接口可能会出现在多个软件包中例如:D API在Javaawt和 Javaawtimage软件包中都存在虽然像Javaawtgeom等一些特殊的软件包也支持D API但 是大量的D API类都存在于Javaawt软件包中 AWT(及以上版本)是JFC的核心AWT为JFC的构成提供了以下的基本结构: ;代理事件模型 ;轻量构件 ;剪贴板和数据传输 ;打印和无鼠标操作 抽象窗口工具集 在开发applet和图形应用程序时一般需要用到AWTAWT是免费Java开发工具包(JDK)的一部分 AWT的作用是给用户提供基本的界面构件例如按钮列表菜单文本域等等AMT 构件主要是用来建立图形用户界面的独立平台此外AWT还提供事件处理结构支持剪贴板数据传输和图像操作随着D 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 将产生一个Windows 菜单同位体;Macintosh JDK将产生一个Macintosh菜单同位体等等 一个Java程序创建并显示AWT构件AWT构件创建并显示本地构件(同位体)AWT开发组决定使用同位体方法这一方法使得交叉平台窗口工具开发变得极为迅速 使用同位体可以避免重新实现本地窗口构件中已包含的实用工具而且使用同位体还能使applet和应用程序保留在本地系统中这是因为同位体实质上是由本地构件组成的而AWT类仅仅是同位体外围的包装与操作工具 虽然在使用AWT时很少需要直接处理同位体但它们的存在却影响其操作结果例如如果没有同位体则某些javaawtComponent方法不会象我们所预期的那样进行工作使用同位体方法可以在记录时间内实现GUI工具构件然而使用同位体也有很多的缺点同位体设计基础存在缺陷并且不能缩放 轻量构件 AWT构件全都是重量构件即它们都具有同位体并且在本地 (不透明)窗口中进行显示这样使用将花费昂贵的代价而且在更改其默认行为时不可以将其派生为子类此外它们必须是矩形的而且不能有透明的背景同位体可以快速产生一个GUI工具构件因为本地同位体做了更多的实际工作而AWT 类所做的仅仅是表面工作因此它很容易开发开发最初的AWT只用了不到个星期的时间但这种效率带的利益在很大程度上被一些不利因素抵销了比如基本的同位体结构有限的事件模式以及同位体与AWT之间不匹配造成的大量缺陷 版本的AWT引人了轻量构件的概念轻量构件直接扩展了javaawtComponent或javaawtContainer轻量构件没有同位体在其重量容器窗口中显示而不是在其本身窗口中显示轻量构件不会导致与它们自己关连的不透明窗口的性能损失而且还可以有透明的背景其中有透明背景的性能意味着即使轻量构件的界限域实际上是矩形的它也可以显示为非矩形 SWing的历史 要了解Swing首先必须了解AWTAWT是Swing的基础 Java的发展速度超出了人们的想象Java API中最可视的部分AWT突然成为了人们关注的焦点遗憾的是原来的AWT不能满足发展的需要 原来的AWT不是为许多开发人员使用的功能强大的用户界面 (UI)工具包而设计的其设计目的是支持开发小应用程序中的简单用户界面例如原来的AWT缺少许多面向对象UI工具包中所能见到的特性例如剪贴板打印支持和键盘导航等特性在AWT中都不存在原来的AWT甚至不包括弹出式菜单或滚动窗格等基本特性而弹出式菜单和滚动窗格是开发现代用户界面的两个基本元素 此外AWT的下层构件还有严重的缺陷人们使AWT适应基于继承的具有很大伸缩性的事件模型甚至更糟基于对等组件 (peer)的体系结构也被用于AWT该体系结构注定要成为AWT的致命弱点 为了尽快推向市场和保持本地的界面样式于是产生了基于对等组件的体系结构而该体系结构注定是要失败的对等组件是完成薄弱的AWT对象所委托任务的本地用户界面组件 对等组件负责完成所有的具体工作包括绘制自己对事件做出反应等这使得AWT组件除了在适当的时间与其对等组件交互外无事可做由于AWT类只是较复杂的本地对等组件的外壳所以AWT的早期开发人员能在最快的时间内创建组件例如javaawtPanel类只包含十二行代码 另外对等组件的设计也有严重的缺点首先在大多数平台上对等组件都是在本地窗口中绘制的每个组件一个本地窗口实在不能得到高性能为此含有大量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大大地偏离了它原来的目标随着Swing版本的推出虽然大量的IFC技术仍然嵌在Swing中但是Swing与IFC相似的部分已大部分消失了今天在一个功能全面的用户界面工具包中Swing提供了AWT和IFC中最优秀的成份 轻量组件与重量组件的比较 轻量组件首次出现在AWT版本中AWT最初只包括与本地对等组件相关联的重量组件这些组件在它们自己的本地不透明窗口中绘制 相反轻量组件没有本地对等组件而且在它们的重量容器的窗口中绘制 由于轻量组件不在本地不透明的窗口中绘制因此它们可以有透明的背景透明的背景使显示的轻量组件可以是非矩形的虽然所有组件 (重量的或轻量的)都基于一个矩形边框 Swing组件几乎都是轻量组件那些顶层容器:窗体小应用程序窗口和对话框除外 因为轻量组件是在其容器的窗口中绘制的而不是在自己的窗口中绘制的所以轻量组件最终必须包含在一个重量容器中因此Swing的窗体小应用程序窗口和对话框都必须是重量组件以便提供一个可以在其中绘制Swing轻量组件的窗口 好了这是对AWT和Swing的一个概述更具体的应用需要在不断的实践中去体会 |