Java图形类库.docx

Java图形类库.docx

《Java图形类库.docx》由会员分享，可在线阅读，更多相关《Java图形类库.docx（8页珍藏版）》请在冰豆网上搜索。

Java图形类库

Java图形类库

Java图形类库概述

　　1994年，全球信息网的迅猛发展为Java提供了良好的契机。

Java的首次公开露面始于网页上一个小小的转动着的咖啡杯。

这个Javaapplet的出现打破了Web站点沉寂的风格，为原本以静态文字和图片为主的互联网世界带来了新的生机和情趣。

经历了几年的发展，Java已经从最初的Web页面修饰工具发展成如今的Internet/Intranet计算平台。

Java的应用也已经不仅仅局限于客户端，由于针对服务器端应用的Java技术的推出，如Servlet、RMI、企业JavaBeans等等，更多的开发人员开始使用Java开发和部署企业关键任务应用。

　　Java的广泛应用，除可以归因于其强大的跨平台特性、内在的安全机制及其分布式计算等特性外，Java提供的图形类库也可以说功不可没。

Sun公司在其发布的早期Java版本JDK1.0中就提供了Java图形类库AWT（抽象视窗工具库），用于图形用户界面的开发。

在JDK1.1中AWT又不断地得以改进。

此后，为满足商业化应用对图形用户界面的更高要求，Sun公司与Netscape、IBM公司合作共同开发了新一代Java图形类库JFC（Java基础类）。

　　本文将介绍Java图形类库的基本概念、结构及编程方法。

我们将从AWT入手，介绍AWT的组件、布局管理及事件处理机制。

并以此为基础，介绍JFC的体系结构及其各个组成部分，其中会详细介绍Swing组件的组件模型及其特性。

　　AWT简介

AWT是Java提供的面向对象的图形用户接口框架，可用于生成现代的、鼠标控制的图形应用接口，这并不是Java本身的创新。

但是，用Java设计和实现的GUI无需修改，就可以在各种软硬件平台上运行，这才是Java极具革命意义的地方。

但是，这并不意味着AWT展现给你的是一种全新的GUI风格。

如果你已经习惯了Windows的图形用户界面，或者是Motif的图形用户界面，那么AWT尊重你的这种习惯。

在AWT中，每一个可视化的GUI组件都有一个本地的对等端（nativepeer），负责该组件的显示与外观。

所以用AWT构造的Java应用程序，在PC机的Windows系统上运行将保持Windows的GUI风格，而拿到Sun工作站上运行则将具有Motif图形用户界面的风格。

　　GUI组件

　　AWT提供了构造图形用户界面所需要的基本GUI组件。

这些GUI组件由java.awt包中相应的类来表示，并通过它进行访问和使用。

java.awt包是java基本包中最大的一个包，其中定义了所有GUI组件类，以及其他用于构造图形用户界面的类，如字体类Font，绘图类Graphics和图像类Image等。

AWT所提供的GUI组件大致分为三类，即容器组件、基本组件和菜单组件。

　　容器组件

　　所谓容器组件，是指能够包含其他组件的组件。

一个设计良好的用户界面应该是高度结构化的，而不是一些简单GUI组件的无序组合。

而容器组件恰恰有助于实现GUI的结构化。

　　AWT中提供的容器组件有Panel、Window、Frame、Dialog。

其中Panel没有具体的图形表示，但它却是实现GUI结构化的一个至关重要的组件。

我们通常用它来实现GUI基本组件的组合；Frame则定义了一个包含标题条、系统菜单栏、最大化/最小化按钮及可选菜单条的完整的窗口；而Dialog主要用于实

的缺省布局管理方式。

与FlowLayout不同的是，如果使用BorderLayout进行布局管理，那么在加入GUI组件的时候，就需要明确指出加入的位置，例如：

　　setLayout（newBorderLayout（））;

　　add（"Center",newButton（"Button"））;

　　CardLayout：

CardLayout提供了一种基于卡片式的布局管理方式。

在AWT应用中，可以将某一GUI组件加入到一个指定名字的卡片中，例如：

　　setLayout（newCardLayout（））;

　　add（"CardName",newButton（"Card1"））;

　　这里，卡片名字是唯一的，可用于引用相应的卡片。

一般而言，加入到卡片中的GUI组件通常是Panel对象，因为Panel对象又可以包含其他GUI组件，并按照其自身的布局管理方式来管理它们。

为便于在一组卡片之间来回切换，CardLayout定义了一系列方法，如first、next、previous、show等。

　　GridLayout：

GridLayout提供了一种基于栅格的布局管理方式。

栅格的行数

和列数可以在创建GridLayout对象时指定。

采用GridLayout进行布局管理，容器中的每个组件将占据大小完全相同的一个栅格。

向栅格中布置GUI组件有两种方法：

一种是使用缺省的布置顺序，即采用add（Componentcomp）方法按照从左向右、从上到下的顺序加入GUI组件；二是采用add（Componentcomp,intindex）将组件加入到指定的栅格中。

　　GridBagLayout：

GridBagLayout是建立在GridLayout之上的一种布局管理方式。

较GirdLayout而言，GridBagLayout更复杂，也更灵活，容器中的每一个组件可以占据一个或多个连续的栅格。

GridBagLayout布局管理器是借助于类GridBagConstraints来限制每个组件所占据的横向和纵向栅格的个数。

　　基本GUI组件

　　基本GUI组件是构成用户界面的基本元素。

这些GUI组件不能独立存在和显示，而必须先将之加到容器组件中。

在java.awt包中定义的基本GUI组件类有：

Button、Canvas、Checkbox、Choice、Label、List、ScrollBar、TextFie

ld和TextArea。

所有的基本组件类都是Component类的子类。

Component类中

定义了所有GUI组件共有的属性和方法。

　　作为Component的子类，所有基本GUI组件类均可以继承Component类中定义的属性和方法。

除此之外，每一个组件类中又都有针对本身应用特点而定义的属性和方法。

　　菜单组件

　　Java中的菜单组件是一类特殊的组件。

同其他GUI组件不同，菜单组件并不是Component类的子类，而是从MenuComponent类中派生出来的。

这也就是说菜单组件是不能通过add方法加入到容器组件中去的。

在AWT中，菜单系统是通过另外一种联系机制加入到窗口中的，即Frame类的setMenuBar（MenuBarmbar）方法。

　　AWT中定义的菜单组件有四类：

MenuBar,Menu,MenuItem和CheckboxMenuItem。

MenuBar是窗口的菜单条，其中定义了add方法，用于向菜单条中加入子菜单Menu和菜单项MenuItem；Menu是子菜单，它可以通过add方法来组合MenuItem和其他子菜单；而MenuItem则是最基本的菜单项，MenuItem还有一个特殊的实例CheckboxMenuItem，主要用来表示菜单项的开关状态。

通过AWT定义的这四个菜单组件，我们可以创建一个完整的菜单系统。

　　AWT事件处理

　　前面简要介绍了AWT提供的GUI组件。

那么，是不是有了GUI组件就可以构造一个应用系统的用户界面呢？

答案是否定的，因为这样构造出来的图形用户界面是无法与用户交互的，一个完整的用户界面系统还必须具备事件处理能力。

　　从JDK1.0到JDK1.1，AWT的事件处理机制有了很大的变化。

在JDK1.1中，AWT采用了一种新的事件处理模型—代理事件模型。

较JDK1.0中的事件处理模型而言，新的事件处理模型不仅更为灵活，而且完全支持JavaBeans。

　　AWT的代理事件模型中有如下三个角色：

　　事件源：

即产生或发出事件的对象。

例如，用户点击了图形用户界面上的一个按钮，按钮就会产生一个鼠标按下的事件。

此时，按钮就是事件源。

　　事件：

AWT中定义了各种事件类，如鼠标事件（MouseEvent）和窗口事件（WindowEvent）等。

　　事件监听器：

事件监听器用于监听某类事件的发生。

它通过调用事件源中定义的addxxxListener方法（xxx代表某类事件），来登记所需监听的事件。

当该事件源发出此类事件时，事件监听器就会得到通知。

在AWT中，事件监听器是java.awt.event包中的一类接口，其中定义了被监听的事件发生时，系统要调用的方法。

　　新一代Java图形类库—JFC

　　AWT提供了构造applet和application图形用户界面的基本类库。

通过采用“本地对等端”（nativepeer）模型，即AWT中的每一个可视化GUI组件都有一个相应的本地对等端来负责它的显示与外观，从而解决了跨各种软硬件平台显示GUI的问题，为Java最初的成功奠定了基础。

　　AWT的“本地对等端”模型，满足了当时开发人员希望Java在不同平台上运行时，具有本地显示风格的要求，但同时也带来了一些问题：

　　●“本地对等端”模型给GUI的绘画和事件处理带来了很多限制，使得某些方面的GUI编程很难实现：

如采用透明背景色、改变GUI组件外形为其他形状等。

●AWT提供的是本地显示风格，但是随着Internet的普及，更多的开发人员希望网络应用能够具有一致的显示风格。

为解决AWT的“本地对等端”模型带来的问题，Sun公司与Netscape、IBM合作共同开发了新一代Java图形类库—JFC（JavaFoundationClass）。

JFC实际上是AWT的超集，它提供了更丰富的GUI组件和更强的图形/图像处理能力，而且JFC完全向下兼容AWT的应用。

JFC的发布，使得Java在开发客户端应用方面又向前迈进了一大步。

目前，JFC的版本是JFC1.1，它不但可以作为一个单独的包下载，而且已经成为JDK1.2的核心部分。

　　与AWT相比，JFC提供了更丰富的GUI组件，即Swing组件。

Swing组件全部是“轻型”组件（即不需要“本地对等端”的组件），具备“可插接的外观和感觉”特性。

此外，JFC还提供了丰富的二维图形/图像支持、系统级的拖放功能和对辅助技术的支持。

下面将分别介绍这四部分特性：

Swing、Java2D、Drag&Drop和JavaAccessibility。

　　Swing

　　Swing组件集是JFC提供的一套新的GUI工具，它简化了基于图形界面的窗口系统的开发。

Swing组件是所谓的“轻型”（lightweight）组件，因为这些组件同AWT中的基于本地对等端的组件（我们称之为heavyweight组件）不同，这些组件没有对应的对等端，也即不需要跟操作系统相关的本地UI代码。

因此，实现这些组件所需要的代码量更少，而且减少了在不同平台上运行可能带来的不一致性。

　　此外，开发人员使用Swing可以方便地选择自己需要的GUI风格：

本地的显示风格、统一的Java显示风格或用户定制化的显示风格。

总之，当你开发客户端应用时，Swing给你带来了更多的灵活性和更强大的功能。

　　Swing&AWT

　Swing是对AWT的扩展，而并非是Swing替代了AWT。

从体系结构的角度来说，Swing构筑在AWT（并非AWT的全部）之上，如图4所示。

Swing位于JFC的一系列API之上，例如Java2DAPI、Drag&DropAPI和AccessibilityAPI。

因为这些API都需要依赖于本地代码来执行一些任务，而Swing的组件是不依赖于本地对等端的。

因此，Java2DAPI、Drag&DropAPI和AccessibilityAPI都是JFC的组成部分，同时也是AWT的组成部分，但是它们都不属于Swing。

　　Swing组件介绍

　　Swing提供了一套丰富的“轻型”GUI组件，定义在javax.swing包中。

Swing

组件涵盖了AWT中业已提供的GUI组件，这些组件的类名即是AWT的组件类名加上前缀“J”。

此外，为了满足商业化桌面应用的需求，同时简化应用的开发和部署，Swing还定义了一套新的高层次的GUI组件。

其中基本GUI组件新增加了JTable、JTree、JSlide、JProgressBar、JToolTip以及JFileChooser和JColorChooser，并将Choice组件更名为大家熟悉的ComboBox；而容器组件则新增加了JSplitPane、JTabbedPane、JToolBar、JInternalFrame和JLayeredPane。

　　Swing组件，无论是基本组件还是容器组件，都沿用了AWT（JDK1.1）的事件处理模型。

除了java.awt.event包中定义的事件类和事件监听器接口，Swing还在javax.swing.event包中为新增加的组件定义了相应的事件类和事件监听器接口。

　Swing组件体系结构

　　Swing组件早期采用的体系结构是“模式－视图－控制器”（model-view-co

ntroller），简称为MVC。

MVC模型的应用可以追溯至SmallTalk，它是GUI对象常用的一种结构设计。

在MVC模型中，一个可视化应用可以分为以下三个方面：

　　模式：

代表应用的数据

　　视图：

是应用数据的可视化表示

　　控制器：

接受用户在数据视图上的输入，并相应地改变数据模式。

　　在Swing开发小组试图采用MVC作为Swing组件的结构模型过程中，他们发现MVC的视图和控制器部分密切相关，这种简单将应用切分为上述三部分在实际工作中效果并不理想。

因此，经过Swing开发小组的讨论，他们采用了一种改进的MVC模型，即“分离模式”模型，如图5所示。

在这种结构模型中，模式独立出来，而视图和控制器则合并成为一个单一的UI对象，来负责Swing组件的外观和感觉（lookandfeel，简写为LAF）。

　　在这种结构模型中，包括UI管理器、UI对象和模式三部分：

　　UI管理器

　　为了管理Swing组件的显示特性，Swing在javax.swing包中定义了UIManager类，以跟踪和管理Swing组件当前的和缺省的LAF。

目前Swing提供三种GUI显示风格：

JavaLAF、WindowsLAF和MotifLAF。

开发人员可以通过UIManager的setLookAndFeel方法，动态地设置Swing应用的显示风格。

　　UI对象/UI代理

　　Swing的每一个组件都有处理其自身的视图和控制器的能力。

每一个Swing组件类都不直接处理与其显示相关的部分，而是将它代理给当前安装的LAF模块所提供的UI对象，所以也称之为UI代理。

UIManager对Swing组件的外观和显示的控制，是通过它与Swing组件的UI对象的通信来实现的。

UIManager和UI代理与Swing组件的可插接的显示和感觉（PluggableLookandFeel）特性密切相关。

　　模式Model

　　通常我们认为一个设计良好的程序应当是以体系结构为中心的，而不是以用户界面为中心的。

而Swing在设计过程中以及其后的版本更新过程中，始终坚持了这一点。

基于此，对每一个能够存储或操纵数据/值的组件，Swing都定义了一个单独的Model接口，开发人员既可以使用系统提供的缺省数据模式，也可以实现自定义的数据模式。

　　在Swing中，Model接口可以分为两类：

即GUI状态模式接口和应用－数据模式接口。

前者是定义了GUI组件的可见状态的接口，例如ButtonModel接口中定义了按钮当前的状态。

而对于更复杂的GUI组件，如JTree、JTable等，则定义了应用－数据模式接口，这类接口用于管理复杂的数据信息。

　　实际上，Swing的“分离模式”模型并未明确区分GUI状态模式接口和应用－数据模式接口。

但是了解这两种模式接口的不同，有利于开发人员根据应用的需要和组件的特点灵活地进行编程。

　　可插接的外观和感觉

　　可插接的外观和感觉（Pluggablelook&Feel，PL&F）是Swing的一部分，

它提供了一种灵活的机制：

开发人员既可以选择JavaLAF，在不同平台上获得一致的显示风格，也可以选择依赖于平台的LAF。

如果系统提供的LAF仍不满足应用的需要，开发人员可以利用Swing提供的“可插接的外观和感觉”特性来构造一个新的、定制化的LAF。

　　PL&F的实现与我们前面提到的UIManager和UI代理密不可分。

每一个Swing组件特定于外观和感觉的部分都代理给相应的UI对象了。

Swing在javax.swing.plaf包中，定义了一套抽象类来代表UI对象，其命名规范是将Swing组件类名的前缀“J”去掉，再加上后缀“UI”。

每一个LAF模块，包括系统安装的和用户自定义的，都必须提供这些抽象类的实现。

通常，UI代理是在Swing组件的构造函数中被创建，开发人员可以通过Swing组件的setUI/getUI方法来设置/获取之。

设置Swing组件的UI代理的过程实际上就是安装组件的LAF的过程。

　　当一个用Swing编写的应用程序被JVM载入的时候，Swing缺省的动作是将组件的LAF初始化为JavaLAF。

如果希望采用其他的LAF，只需要调用UIManager中定义的setLookAndFeel方法即可。

UIManager类还定义了各种方法，以方便用户获取有关LAF的各种信息，如本地系统采用的LAF、当前的和缺省的LAF及系统安装的所有LAF等。

　　除采用系统提供的LAF外，还可以定义自己需要的LAF。

Swing定义了抽象类javax.swing.LookAndFeel，它代表了实现一种LAF所需要的全部信息。

所有的LAF都需要继承抽象类LookAndFeel，并实现其中的抽象方法。

通常，一个LAF模块（如javax.swing.plaf.metal）包含LookAndFeel类的子类（如MetalLookAndFeel）；所有UI代理类（例如MetalButtonUI等）和LAF应用类。

　　Java2D

　　由Sun公司与Adobe系统公司合作推出的Java2DAPI，提供了一个功能强大而且非常灵活的二维图形框架。

Java2DAPI扩展了java.awt包中定义的Graphics类和Image类，提供了高性能的二维图形、图像和文字，同时又维持了对现有AWT应用的兼容。

　　Graphics2D类在Java二维图形功能中起着相当重要的作用，在该类中提供了各种设置二维绘画属性的方法，从而使一般的开发人员能够像绘画专家一样画出高品质的二维图形/图像。

Graphics2D主要有如下的绘画属性：

　　填充模式：

填充模式既可以是一种颜色，也可以是Java2D中定义的填充模板，如GradientPaint或TexturePaint。

Graphics2D的setPaint方法可用于设置填充模式。

　　透明度：

Java2D允许在绘画时指定透明度，以使下面的图形能够透过当前绘制的图形/图像部分地显示出来。

Graphics2D的setComposite方法可用于设置绘画透明度。

　　画线模式：

Java2D允许在绘画时指定线的宽度、是否用虚线以及线与线联接的模式。

这些设置是通过Graphics2D的setStroke方法来实现的。

　　字体：

在Java2D中允许本地字体的使用。

通过Graphics2D的setFont方法，

用户可以自由选择所需要的字体。

　　此外，Graphics2D中还定义了各种坐标变换方法，开发人员可以方便地进行图形/图像的变换和移位。

Java2DAPI，除了java.awt包中定义的Graphics2D和相关的绘画类外，还包括java.awt.image包中定义的图像类和java.awt.geom包中定义的二维图形类。

　　Drag&Drop

　　JavaDrag&DropAPI定义在java.awt.dnd包中。

拖放功能（dnd）是JDK1.2中新增加的JFC特性。

其设计目标是实现与平台无关的拖放操作，包括Java应用之间的拖放操作和java应用与本地应用（如Win32OLE、CDE/Motif等）之间的拖放操作。

JFC中拖放功能的实现极大地改善了Java应用与非Java应用之间的互操作性。

　为了实现与平台无关的可拖放性，JFC在java.awt.dnd包中定义了一套类和接口，其中最主要的是DragSource、DropTarget类和DragSourceListener、DropTa

rgetListener、DragGestureListener接口。

DragSource、DragSourceListener和

DragGestureListener用于构造可被拖拉的Java组件（拖放源），以及跟踪用户拖

放的动作和状态；而DropTarget和DropTargetListener则用于构造可接受拖放源

的Java组件（拖放目标），以及跟踪拖放的状态。

　　JavaAccessibility

　　由于市场的原因，大多数开发商还未意识到“辅助技术”的重要性。

广义地讲，辅助技术是指所有能够帮助残疾人去做力所不能及的事情的技术。

常用的辅助技术有屏幕阅读器、屏幕放大器等。

JavaAccessibility的设计目标就是使残疾人有更多的机会获取Web的信息。

目前JavaAccessibility包括JavaAccessib

ilityAPI和JavaAccessibilityUtility。

　　JavaAccessibilityAPI定义在javax.accessibility包中。

它定义了构成

Java应用的GUI组件与访问Java应用的辅助技术之间的协定。

如果Java应用完全支持AccessibilityAPI，则该应用就可以与辅助技术（如屏幕阅读器等）兼容。

　　JavaAccessibilityUtility是Sun公司提供给辅助技术厂商的，以便他们的

产品能够访问Java应用。

目前，JavaAccessibilityUtility作为一个单独的软

件包，可以在javasoft的站点上下载。

这个软件包能够支持辅助技术定位和查询

java应用中的GUI对象，并支持这些GUI对象的事件监听器的安装。

　　结束语

　　Java图形类库AWT与JFC是开发客户端Java应用的重要工具。

AWT是Java图形类库的基础，了解AWT，尤其是AWT的事件处理机制和AWT的布局管理，有利于JFC的学习。

作为新一代Java图形类库，JFC提供了一套丰富的GUI组件，其显著特性就是具备PL&F能力；此外，JFC还包容了Java二维特性、系统级的拖放特性和对辅助技术的支持。

　　JFC极大地扩展了AWT的能力，它为开发人员创建和部署商业化的Internet/Intranet应用提供了一个可扩展的、稳定的开发平台。

目前，已有为数众多的可视化集成开发工具厂商宣布了对JFC的支持，其中包括大家熟悉的JBuilder、VisualCafe、PowerJ以及VisualAge等。

利用这些IDE工具，开发人员可以更方便、快捷地开发和部署JFC应用。