JFC vs. AFC

摘要：Java抽象窗口工具包 (AWT)可以看作是通向建立真正跨平台GUI 类库的第一步。这一步走得好，但是还很不够。因为这个宏伟的目标绝不是一朝一夕就能够实现的。我们还需要建立一套更加健 壮可靠的 GUI类库以使用户能够利用，从而开发出先进的应用软件。

为了解决AWT的一些问题，现在出现了两套新的类库。JavaSoft开发的Java Foundation Classes (JFC)以及微软开发的Application Foundation Classes (AFC)。到底谁将胜出将取决于二者的质量和特点，但更重要的是取决于业界对二者的接纳程度。

简介

AWT的问题之一来自它的设计目标。AWT的设计目标是跨平台的GUI类库。它使用其运行的 平台所据有的本地窗口和控制。使用本地窗口和控制有其本身的优点，那就是用户无论在何种平台上运行一个用AWT写成的应用或者Applet，他们总能看到自己熟悉风格的界面。 然而这种方法也存在其缺陷。最明显的缺陷就是被称为“最小交集”的问题。因为AWT 是利用本地窗口和控制，又因为它要跨平台，其所能够提供的功能因而也是最简约的。道 理很明显：界面要反映能够跨多个平台使用的基本服务。而如果AWT中提供的一个特性在其支持的某一个平台上不是“本地特性”时，AWT则必需利用一个模拟层来支持该特性。 如果AWT坚持“一次写成，到处使用”的承诺，则模拟层必不可少。

业界意识到AWT所采用的这种基于本地或者替代关系的窗口工具包策略所存在的问题，有些 技术领先的软件商则已经着手开发自己的类库以解决此问题。这方面的工作造成了两个新 Java类库的出现： Netscape的 Internet Foundation Classes (IFC) 和微软的 Application Foundation Classes (AFC).

IBM, Netscape和JavaSoft达成了协议，共同完善和发展 Netscape的 IFC 技术 (96/12/11面世) 并将新的类库定名JFC。业界巨人携手合作，将 JFC 推向了 GUI 类库大战的最前沿。目前风头最劲的两大GUI类库当属JavaSoft的JFC和微软的 AFC。

回页首

AFC和JFC的背景

1997年4月2日是Java GUI类库的纪念日。Microsoft和JavaSoft不约而同(早有预谋？)地在旧金山 JavaOne开发者大会上宣布了自己的类库。Microsoft宣布AFC的一个预览版本面世。AFC最初是在一月宣布的，但这是它的第一个发布的版本。与此同时，JavaSoft宣布其正与Netscape及 IBM共同制作JFC。同时在JavaSoft的网页http://www.javasoft.com上发布JFC的一个预览版本。

AFC在微软的网页上作为其SDK 2.0的一部分发布。参见http://www.microsoft.com/java。在此 之前，对AWT批评的一个中心内容即是用户必须“蠢化”界面来实现跨平台。而此两者都提供了高级用户界面特性从而避免了为跨平台和实现网络应用而“蠢化”界面的烦恼。

这两个类库都支持所谓“无替换”和“无窗口”的构件。这意味着用户界面的控件由类库自 己画出而非依赖于该应用运行的平台。这种方法的结果就是代码的界面和行为在任何平台上都保持一致。因为这些类库并非使用本地 窗口或控制而是通过内部实现，它们就与平台 的用户界面脱钩了。

有些人士更是提出：通用的用户界面风格是未来的趋势，而AWT的“本地化”风格则将成为 历史。笔者认为，当平台成为一个越来越无关的因素时，通用的JFC或AFC界面风格将成为标准。试想如果JAVA如果能想我们希望的那样一统江湖的话，那么人们当然会希望JAVA 应用具有相同的界面风格。使用户无论是通过装有NT或OS/2的PC还是通过Macintosh或NC甚至PDA访问应用都能感到一样舒适。

回页首

微软AFC

当我们提到AFC时，很多人指的是它的GUI类库部分。事实上，AFC并不止于此。 AFC包含 以下的包：

• com.ms.ui-用户界面控件 (人们说afc时，一般指的是这个包的功能。)
• com.ms.fx-图形包。这个包包括处理图形，字体和文本的java类。
• com.ms.ui.event-事件处理包。这个包包含对java 1.1事件模型的支持。
• com.ms.ui.resource-资源文件。这个包包含对java应用中win32资源文件的支持。
• com.ms.util.cab-cab文件。这个包包含对cab文件压缩和解压的支持。

这里讨论将主要集中在AFC的用户界面方面。

回页首

AFC概览

AFC类库是JAVA应用开发的高层框架。AFC是用Java写成，这意味着它可以跨平台在任一 台JAVA虚拟机上运行(包括浏览器)。AFC提供与AWT类似的构件模型，支持component, container和layout manager.

AFC的两个设计特色分别是轻量级的类和无窗口/无替换的构件。AFC并未直接扩展AWT的 Component类。AFC的设计者们认为这个类太过庞大，因此，AFC包含有自制的UIComponent类。据信这个类比AWT同等的Component 类要少消耗内存。不扩展 AWT Component 类的 决定影响了AFC与AWT的兼容性。参见下面AFC/AWT 兼容性一章。

因为AFC不使用其运行平台上的任何本地代码，它就能提供具有跨平台和可移植性的通用 风格界面。AFC应用的界面风格无论到了任何平台上都能保持相符。AFC使用了AWT中的基本frame和对话窗口，但这些类是由AwtUI作为前缀的AFC兼容类包裹的。关于AFC兼容类 下面还要详细讨论。

AFC 支持Win32资源格式，允许开发者在AFC Java应用中使用Win32资源。这种支持还有能 用Win32支持的方式提供NLS(本地语言支持)的额外便利。

AFC支持1.0.2和1.1版事件模型。AFC应用只能支持其所使用的JVM的事件模型版本。但是 AFC构件则既可使用1.02也可使用1.1。 AFC构件从内部实现这些模型，但是它的界面与AWT略有不同。详见下文AWT可编程性一节。

回页首

JavaBeans支持

标准AFC构件，例如UIPushButton, UIRadioButton等，不是JavaBean。AFC的JavaBean支持只 限于AwtUI* 兼容类。也就是说，要想使用AFC构件做为 JavaBeans则必须使用兼容类将其包裹起来。这将在需要使用JavaBeans支持的情况下将影响AFC应用的性能。

回页首

AFC用户界面特性

AFC提供一套强有力的用户界面控件，而 Win32 程序员将对这些控件感到熟悉。所有的 Win32控件都在AFC的 com.ms.ui 包里提供，而且还有一些额外的特色。包中类的名字， 除了 AwtUI 和 UI 前缀，很多类名都对Win32程序员很熟悉。

UI 前缀被用做AFC用户界面类的标准名。 AwtUI 前缀指与AWT兼容的类。这样做是为了允许 在AWT窗口中使用AFC控件。详见AFC/AWT兼容性 一节。表1给出一些 AFC用户界面控件的列表以及它们在AWT中的对应控件。

表1：一些 AFC用户界面控 件的列表以及它们在AWT中的对应控件

一些值得注意的AFC特性包括HotTracking和BandBox。HotTracking特性允许控件当鼠标停留 在其上时改变外观。这样用户就能知道这里有可以发生交互的控件。外观变化无常可以是 下列之一:

• 文本变化
• 背景色改变
• 图改变
• 控件轮廓改变(从平铺变成浮起)

BandBox可以用来创建可改变大小的工具条。可以将一系列控件加到UIBand 对象上，再将 UIBand 对象加到 bandbox。 然后UIBandThumb 对象被加到bandbox，这样就可以允许用户定制工具条的大小和位置了。

回页首

AFC 布局管理器

AFC除了支持现有的AWT的一部分布局管理器外，还增加了一些新的布局管理器。AFC中有对应FlowLayout, BorderLayout 和 GridLayout 的布局管理器，它们的名字，不出所料的叫做 UIFlowLayout, UIBorderLayout 和 UIGridLayout. Card 和 GridBag 布局在 AFC 中没有对应，因此不能在 AFC container 中使用。AFC 新增的布局有 BarLayout, FixedFlowLayout, VerticalFlowLayout, RowLayout, SplitLayout, TabLayout, TabListLayout, ThreePanelLayout 以及 TreeLayout.

回页首

AFC/AWT兼容性

AFC并非AWT构件结构的直接扩展，因此开发者们不能自由的在应用中混和使用AWT和AFC 构件。为了与现存的AWT兼容， AFC使用了称为AWT兼容类的技术 (就是那些有 AwtUI 前缀的类) 这些类充当AWT container和AFC构件之间的桥梁。换句话说，如果你想在 AWT container 中包括任何AFC构件，你就必须使用AwtUI* 类而非标准的UI* 类。我认为这种设计是对AFC使用的一大障碍。详见以下AFC可编程性一节。

回页首

AFC可编程性

笔者为了准备这篇文章，安装了微软的Visual Studio和SDK for Java 2.0 Beta 2。然后笔者又 写了一些AFC代码以检视平台状况以及其能提供的功能。看起来AFC主要的问题就是它并非直接扩展AWT。当用户试图在同一个container中混和使用AWT和AFC时，这个问题就显现 出来。因为这时必须使用AWT兼容类，所以编码显得不够明晰。此外，因为AFC，AWT和AWT兼容类不能轻易混和使用，程序员在编程时必须对此特别注意他们到底在处理哪一类 构件。下表列出了在AWT container, AFC container 和AWT兼容container中混和使用AWT构件AFC构件以及AWT兼容构件时可以做和不能做的事。

在AWT container中 (例如Panel):

• 你能嵌入标准AWT构件 (例如Button).
• 你不能嵌入标准AFC构件，例如你不能包括UIPushButton
• 要嵌入AFC构件，你必须使用AWT兼容类。如 AwtUIPushButton而非UIPushButton.

在AFC container 中(例如UIPanel):

• 你能嵌入标准AFC构件 (例如 UIPushButton).
• 你不能嵌入标准AWT构件，例如你不能包括 Button.
• 你不能嵌入任何AWT兼容构件，例如, AwtUIPushButton.

在AWT兼容的container中 (例如AwtUIPanel):

• 你能嵌入标准AFC构件(例如, UIPushButton).
• 你能嵌入AWT兼容构件 (例如AwtUIPushButton)
• 你不能嵌入任何标准AWT构件(例如Button).

在这里，主要的障碍是当你想在AWT container中使用AFC构件时，你必须使用AWT兼容类， 而不是标准AFC构件。(见表1). 而当你使用AFC container时，则只能使用标准AFC构件而不能使用任何AWT构件(见表2)。 另外，当你使用AWT兼容container时， 你也不能包括标准 AWT 构件(见表3)

笔者一再发现必须回头去看文档以确定自己是否在使用正确的类。 例如，如果我想把一个button放进container，我是要使用UIPushButton，AwtUIPushButton 还是Button？而这个是由你使用的container的类型决定的。这样，使用AFC的编程就变得 格外讨厌。

class AWTButtonDemoPanel extends Panel
{
 AWTButtonDemoPanel()
 {
 Button AWTButton = new Button("AWT button");
 AwtUIPushButton AWTUIPushButton = new AwtUIPushButton("AwtUIPushButton");
 UIPushButton AFCUIPushButton = new UIPushButton("AFCUIPushButton");
 add(AWTButton);
 //OK...standard AWT component
 add(AWTUIPushButton);
 //OK...AFC button used in AWT wrapper
 add(AFCUIPushButton);
//Compile error! Will not compile since AWT Panels don't
//know anything about AFC components
 }
}

表 1: AWT Container 及 AWT, AFC, 和 AWT 兼容构件

class AFCButtonDemoPanel extends UIPanel
{
 AFCButtonDemoPanel()
 {
 UIPushButton UIPushButton = new UIPushButton("AFC UIPushButton");
 AwtUIPushButton AWTUIPushButton = new AwtUIPushButton("AwtUIPushButton");
 Checkbox AWTCheckBox = new Checkbox("AWT Checkbox");
 add(UIPushButton);
 //OK...standard AFC Component
 add(AWTUIPushButton);
//Compile Error! Will not compile since UIPanel does not
//support the AwtUI* compatibility classes.
 add(AWTCheckBox);
//Compile error! Will not compile since UIPanel does not
//support standard AWT components.
 }
}

表2: AFC Container 和 AFC, AWT 兼容以及 AWT 构件

class AWTCompatibleDemoPanel extends AwtUIPanel
{
 AWTCompatibleDemoPanel()
 {
 UIPushButton UIPushButton = new UIPushButton("AFC UIPushButton");
 AwtUIPushButton AWTUIPushButton = new AwtUIPushButton("AwtUIPushButton");
 Checkbox AWTCheckBox = new Checkbox("AWT Checkbox");
 add(UIPushButton);
 //OK
 add(AWTUIPushButton);
 //OK
 add(AWTCheckBox);
//Compiles OK! However, throws IllegalArgumentException
//at runtime. Parameter to add must be a subclass of
//AwtUIControl.
 }
}

表3: AWT 兼容container 和AFC, AWTUI*-兼容, 及AWT 构件.

另一个令人讨厌的音素是AFC的事件模型。在AFC中，你不是象在AWT或JFC中一样实现 ActionListener 接口， 而是要实现一个 IUIActionListener 接口。 你不是象在 AWT 或 JFC 中一样重载 public void actionPerformed(Action event); 方法， 而是重载 public void actionPerformed(UIActionEvent event) 方法。 对于其他事件类也是这样。 AFC 中所有的 事件和listener类都是以UI为前缀的。AFC的另一个弱点是它不支持adapter class。Adapter class是AWT中为开发者方便使用1.1版事件模型而采用的类。 所有的这些弱点， 如果 你能理解 AFC 库的设计特点都不难理解，但是它确实会使一个理解了 AWT1.1版事件 模型的程序员感到不便。

JavaSoft的 Java基础类-- Java Foundation Classes (JFC)JavaSoft的JFC是微软AFC的主要竞争对手。二者之间的争斗因为微软宣布将不随其 JAVA 虚拟机附带JFC而升级。 这也就意味着如果 JFC 的应用如果跑在 Window 平台上 时将需要一个非 微软的 JAVA 虚拟机

JFC诞生于Netscape对其IFC类库所做的工作。Sun, Netscape和IBM联手共建JFC， 并将和 JDK1.2 一同推出。当人们提到JFC时，一般是指它的用户界面部分，叫做Swing 或者 SwingSet.

JFC实际包括如下部分：

• 高层用户界面构件-swing
• 2-d 图形
• 拖放
• 可插入的界面风格
• 易用特性

回页首

JFC概览

JFC的设计中将AWT作为它的一个子集。也就是说，JFC是AWT的直接扩展。它增加了许多 新的构件和服务。在JFC中所有新的构件都是直接从AWT的Component类继承而来。这样就 使JFC和AWT完全兼容。

JFC有两个设计特色是与AFC相同的。那就是它使用了轻量级的类以近无替换，无窗口的构 件。同样JFC也未使用任何本地代码去绘制构件。这样JFC就可以跨平台，可移植的具有通用界面风格的类库了。JFC还提供一种叫做可插入界面风格的技术，它允许应用动态改变 界面风格。

JFC必须在JDK 1.1.2或更高版本运行，因此，它只支持1.1版本事件模型。

回页首

JavaBeans支持

所由JFC的构件都写成JavaBeans。所以用JFC构件开发者可以享用JavaBeans的一切好处。

回页首

JFC用户界面特色

JFC提供一套丰富的用户界面构件以增强用户图形界面(GUI)应用。它不仅提供AWT的所有 构件，而且新增了许多高层构件。为区分AWT类和JFC类，所有JFC类都带有前缀"J". 新 增高层构件请见表2 .

JFC的一个独特而有用的特色是它的DebugGraphics选项。DebugGraphics特色可以用来测试 图形是否绘制正确。使用DebugGraphics时，你能够把构件的某部分变成高亮(亮红色)，并观察绘制操作的执行过程。

JFC的另一个用户界面主要特性是可插入界面风格。它允许在运行状态下动态改变一套 (如所有按纽)或全部用户界面的外观。JFC具有可插入的界面风格，它可以允许用户在运行 状态动态改变一些或全部的界面风格。

回页首

JFC可编程性

笔者下载了1.1.3版本的JDK和JFC的源码并且用它们开始编程。笔者使用AWT的技巧并且 几乎立刻就可以熟练的进行JFC编码了。在JFC中使用AWT类易如反掌，区别仅仅是类的 前缀"J"。如果你想用JFC button，写JButton，而如果你想用AWT button,写Button 即可。 不用担心混用JFC和AWT构件及container,它们之间可以无缝联接，混用非常容易。

回页首

JFC布局管理器

JFC支持现存的AWT布局管理器并且增加了一个新的。新布局管理器叫做SpringLayout。 SpringLayout允许用户定义当某构件改变大小时哪块空间应该相应改变大小。可定义的空间有：左边缘，右边缘，上边缘，下边缘，宽度和高度。这些空间可以设置为弹簧或固定式 (spring 或strut) 弹簧属性的空间随整体变化而变化，而固定属性的空间只要有可能就不发生 变化。

回页首

JFC/AWT兼容性

JFC在设计上与AWT完全兼容，因此你不必担心会搞混不同的构件模型。这种兼容性在用户 使用JFC的构建基于AWT代码的新应用时显得格外重要。

回页首

AFC/JFC 性能比较

为了比较性能，我首先用JFC编写了一个应用 (见 附录 A). 该程序让你创建一个带有panel的 frame窗口，panel上的按钮数目由用户指定。这个应用程序测试了性能的三个方面：

• 带有按钮的frame的创建时间
• 按钮的布局时间
• 按钮的重画时间

一旦该应用程序能在JFC下正常的工作，我便将代码块拷贝到Microsoft Visual Studio 中并把它转换为能与 AFC 相兼容（参见 附录 B)。这种转换既简单又直接。应用程序的设计不必改变被用来只作改变的类名。当编译通过后，AFC 程序将第一次正常的工作。
两个程序的设计相同。我覆盖了 paintAll() 和 layout()法以捕捉重画和布局的时间（在 JFC 代码中，我实际上覆盖了 doLayout() 方法,因为 layout() 对与1.1来说已不在使用）。

代码在以下JFC设置下进行编译与执行：

• JDK 1.1.3
• JFC Swing 0.3 开发者的测试版

对于 AFC:

• Microsoft Visual Studio
• SDK for Java 2.0 Beta 2

实际上，在我看到实际的测试结果之前，我注意到JFC看起来要明显的比AFC快。 结果也证明了这一点。 表 3 列出了实际的测试结果。 所有的时间都是通过调用 System.currentTimeMillis() 得到的。我运行创建时间情景，创建100和500个按钮。 布局和重画时间只对100个按钮进行了测试。

所有的性能测试都是在一台带有80MB内存的奔腾133MHz机器上，Window NT 4.0环境下生成的。 另外，每个应用程序都使用-o选项进行编译。

表3：AFC性能与JFC性能对比。

正如你所看到的，JFC在任何一项中的性能都优于AFC，而且优势很大。 更具体一些， JFC 创建 100个按钮的速度比AFC快185%，创建500个按钮的速度比AFC快124%，布局的时间JFC比AFC快239%，重画按钮的时间JFC比AFC快25%。

两个类库都有重画问题和不必要的多次重画和布局，但我对测试版代码的期望向来不高。 随着时间的推移，两个类库都会不断改进，但JFC的确在性能方面有着明显的优势，这是AFC所无法比拟的。

回页首

AFC/JFC特性比较

表3列出了AFC与JFC在特性方面的主要区别。我用适当的方式（黑体大写）注明了哪个类库有更高的性能，更具竞争力。

表3：AFC与JFC的特性比较。

获胜者是.... 基于我对这两个类库的测试中未包括的事实，JFC是显然的赢家。JFC的设计更合理，具有更多的特性并且比AFC易于使用。虽然二者都有对方没有的特性，但AFC所缺少的重要特性要比JFC多。 对AWT的高度支持、拖拽功能和打印功能是AFC所没有的但又极为重要的三个特性。

在二者同时提供的相同特性中，JFC的实现和支持要比AFC强的多。例如，JFC在JavaBeans、一般可编程性和1.1事件模型方面更具实力。另外，与AFC相比，更强的性能也使AFC在这一重要领域更有竞争力。

JFC是用来创建Java应用程序的坚实基础。目前AWT的编程人员将很方便的转向JFC。