JFC vs. AFC: Which GUI toolkit should you use?

An objective, in-depth, technical comparison of both technologies -- from a developer's perspective. Plus: a step-by-step guide to running AFC apps using Sun's JDK 1.1

1 2 3 Page 2
Page 2 of 3

JFC Swing components, derived from AWT Component, are a natural extension of AWT and can be used together with any AWT native or lightweight components in the same container. Notice, however, that since it is based on the AWT Lightweight UI framework, the SwingSet also inherits one caveat from this framework -- the heavyweight sibling will always be "on top" if overlapping with a Swing component, regardless of the desirable painting order. But this is not a problem of the design and implementation of JFC itself. Those who are interested in this issue should refer to the JDK 1.1 AWT documentation for more detail.

JavaBeans compliance

While JFC Swing components are fully JavaBeans-compliant, AFC UI components currently are not. AFC 1.1 does, however, provide a SimpleBeanInfo implementation for its various AWT adapter classes. Notice that these adapters, using the AWT Panel as their very root class, seem to be beans-compliant. The question: Can these AWT adapters truly be used as bean objects to give users access to all the properties of their wrapped AFC UI components?

By default, AFC does not provide a JAR file for its components. To test the JavaBeans compatibility of the aforementioned wrapper classes, we packed all the related AFC packages into a JDK 1.1-compatible JAR file and tried loading the file into the JavaSoft Beans Developer Kit (BDK) BeanBox. As a result, we encountered some exceptions originated from AFC components. We've also performed similar tests using Symantec's Visual Café with no better luck. At this point, we can only conclude the AFC release has not been made fully JavaBeans compliant.

Migration from existing AWT and IFC applications

From AWT to AFC

Migration from AWT to AFC is relatively straightforward because the AFC model is similar to AWT in spirit. A simple guideline for migration is to change AWT control and layout class names to UI<classname>, and graphics class names to Fx<classname>. For example, List and BorderLayout in AWT should be replaced with UIList and UIBorderLayout. Graphics in AWT should be renamed FxGraphics. Since the AFC API is generally similar to AWT's, it's likely that much of the AWT code will continue to compile and even function properly, though the AFC constructors of many AFC control components are different from AWT and have to be set up properly. Awt2afc, a tool bundled with Microsoft Java SDK 2.0, simplifies the code conversion process by inserting suggestions and comments into the original AWT source code. However, manual conversion is still required to make the actual source code modifications.

From AWT to JFC

JFC, being a superset of AWT, makes migration from AWT a simple process, provided your AWT applications use the JDK AWT 1.1 event model. By adding the prefix "J" to the control component class names, you can easily turn an AWT application into a JFC Swing application. The layout manager classes will continue to work with JFC classes also. Existing event-handling code written with the EventListener model will require very little change, if any.

If, however, the application to be migrated originally was written with the JDK AWT 1.0 event model, you have to perform substantial surgery, cutting the event-processing code and moving it to separate event-listener implementations. The effort of separating the event-handling code from the UI code, while not trivial, is worthwhile, considering the benefits it brings to future maintenance and enhancement.

Beside the class name and event model, one of the most important changes that a developer should consider in a migration process is the use of the MVC architecture of JFC.

From IFC to JFC

Netscape's Internet Foundation Classes (IFC) are said to be the predecessor of JFC. However, pre-release versions of JFC continue to evolve and, as of JFC Swing version 0.7, we are hard-pressed to find any similarities to its claimed predecessor. Although some important IFC features and ideas may have been borrowed and embedded into various parts of the JFC systems, the IFC-to-JFC migrating effort could range from simple name conversions in source code to major restructuring of an entire application. JavaSoft and Netscape have both promised tools to help developers migrate their IFC applications, but up to this point we haven't found useful information regarding the availability and technical details of these tools. Having used both class libraries extensively, our experience shows that an effective mechanism on automating the IFC-to-JFC source code conversion is very difficult to implement. We believe that heavy manual modification or even complete rewrite of the IFC source code is inevitable.

Portability and browser support

Because both JFC and AFC are written in pure Java, theoretically they can run on any Java virtual machines (VMs) on any platform. In the following table, we list major VMs and browsers that support JFC and AFC.

Virtual MachineVersionJFCAFC 1.0.2AFC 1.1
JDK VM1.0.2NoYesNo
1.1.xYesNo **Yes *
Internet Explorer3.0.xYes (with Activator early access)YesNo
4.0.xYesYesYes
Netscape3.0.xYes (with future Activator release)YesNo
4.0.4 with JDK 1.1 patchYesYesYes *

* Note: See the sidebar "How to run Microsoft AFC applications using Sun's JDK 1.1" for more information.

** Note: Theoretically, AFC 1.0.2 can work with JDK 1.1-compatible VMs with 1.0 backward compatibility. But AFC 1.0.2 documentation has no reference for JDK 1.1 VM support, and we find AFC 1.0.2 fails to work correctly with JDK 1.1.x.

Advanced features

The original AWT proves to be insufficient to achieve impressive visual effects. AFC has relied heavily on a package called "Fx," which provides extensive font and color support, better text rendering, and an enhanced drawing-primitives API. AFC components are thus able to offer advanced features like text rotation, texture background, and complicated shape rendering. JFC's 2D API, on the other hand, provides a more powerful, flexible, and complete framework that addresses issues of font support, color management, printing, imaging, text rendering, spatial transformation, and related features in a much larger and deeper scope. As a fully functional and general-purpose 2D graphics and imaging programming framework, JFC's 2D API delivers much more than the Microsoft Fx package. Also notice that the 2D API framework is only loosely coupled with Swing, the UI framework, in the sense that Swing does not depend directly on the 2D API but can be enhanced visually through the use of the API in the implementation of its look-and-feel modules. The initial release of Swing is based on the AWT graphics support, and the future release promises to take full advantage of Java 2D. The Microsoft Fx package, on the other hand, is a key element in AFC. Not only AFC components but also AFC application code in many cases have to use Fx classes and interfaces directly.

Drag and drop is not part of the AFC packages. Though we do observe drag-and-drop capability from one of the AFC sample programs distributed by Microsoft, by tracing the code we determined that the Microsoft drag-and-drop implementation is heavily bound to the Windows platform, with native code involved. JFC addresses the issue with much better, robust solutions. It not only provides a platform-independent, drag-and-drop facility for Java GUI clients but also allows integration with platform-dependent, drag-and-drop facilities by permitting Java clients to participate in drag-and-drop operations with native applications.

Both AFC and JFC Swing have integrated "accessibility" into their implementations, thus enabling the construction of assistive technologies that help people with disabilities interact and communicate with their GUI components.

Learning curve and ease of use

As we discussed above, while JFC is extended from the existing JDK 1.1 AWT class hierarchy with each of its components being a subclass of the AWT Component class, the Microsoft AFC derives its own top-level class UIComponent directly from java.lang.Object and has a separate class hierarchy irrelevant to AWT. Interestingly, though, AFC is similar in overall design to AWT. It is based on an architecture that maintains many of the concepts used by AWT. Anyone familiar with the original AWT concepts will easily understand AFC and be able to apply AFC concepts quickly.

JFC, on the other hand, has more ambitious goals that yield a more sophisticated API framework. Encompassing the MVC architecture and pluggable look-and-feel capabilities, JFC has introduced a certain level of complexity in the following aspects:

  • JFC presents a data-centric programming model, quite different from other GUI-oriented toolkits with which most developers are familiar.
  • JFC has introduced many new concepts (such as UIManager, DirtyRegionManager, Renderer, Editor, Tree RowMapper, and TreePath), either unique to its own architecture or not commonly found in other frameworks, that developers need to learn and understand.
  • Advanced components like Tree, Table, TextComponent, and some others, though powerful, are not simple to use. None of their implementations are mapped to one simple GUI component class. Instead, the correct functioning of these components requires a set of related objects working collaboratively. A typical example is the Tree, which has its own package containing interfaces of MutableTreeNode, RowMapper, TreeCellEditor, TreeCellRenderer, TreeModel, TreeNode and TreeSelectionModel, and classes of DefaultMutableTreeNode, DefaultTreeModel, DefaultTreeSelectionModel and TreePath. Some of these classes and interfaces make uses of concepts whose meanings are inexplicit. It's likely that a thorough understanding of them could only be achieved through the study of a combination of instructive documentation and code examples with extensive experiments. Other components like Table and Text also have their own object frameworks wrapped in their own packages. The API of each of these components is, by itself, a tiny programming framework that a developer needs to follow and understand.

In brief, before being able to fully utilize the power of JFC, an application developer has to learn and understand, in addition to the original AWT, the following:

  • JDK 1.1 AWT event delegation model
  • Model-View-Controller (MVC) architecture
  • Concepts of Renderer/Editor and the way they are being used in composite components such as Lists, ComboBox, and Tree
  • Tiny API frameworks specific to each advanced component

Additionally, a developer who wants to create new components extending the existing JFC classes needs to know and understand:

  • JDK 1.1 AWT Lightweight UI Framework
  • JFC pluggable look-and-feel architecture
  • Concepts of repaint batching system (through interfaces and classes of DirtyRegionManager, RepaintManager, and so on)
  • Some details about 2D graphics

To use AFC, an application developer first must understand the JDK AWT theory while a component writer needs to know about AFC's own lightweight framework as well as some 2D graphics. The AFC API is generally consistent with the AWT style, and may seem intuitive to those who are familiar with AWT.

AFC, an AWT replacement that is architecturally independent of and incompatible with AWT, provides a set of APIs very similar to AWT in style that an AWT programmer can learn and use quickly. JFC, an AWT extension logically derived from the AWT hierarchy, provides a complicated framework that requires a longer learning curve for an AWT programmer who wants to fully exploit its great power. In brief, we feel that AFC has made a developer's AWT programming skill highly reusable while JFC, though preserving the usefulness of the skill, has diminished that skill's significance to make the experience with AWT insufficient. This is the trade-off for adapting the MVC architecture: You obtain its various benefits, but at a cost.

Conclusion

Microsoft AFC is easy to learn and use. It would possibly require less effort to migrate a JDK 1.0-based GUI application to JDK 1.1 using AFC. But AFC employs an event model that is outdated and inefficient. Components written with AFC also may have problems with beans compliancy. Notice, too, that AFC is currently tightly bundled with Microsoft Internet Explorer and SDK, though it is completely possible to unbundle it as a standalone class library. JFC, on the other hand, is fully beans-compliant and has employed an efficient event model that results in prominent performance improvement. Migration of an existing AWT-based application using the JDK 1.1 delegation event model to a JFC-based application would be trivial. But rewriting a 1.0-based GUI application to JFC would require structural changes on the application code. Furthermore, the learning curve of JFC is not necessarily a smooth one.

As you have seen, both toolkits have their own advantages and disadvantages. If you consider pluggable look and feel an important feature for your application, or if you need the flexibility and scalability of a MVC architecture in your object-oriented application development, there isn't much reason for you to hesitate -- JFC is an obvious choice and worth the learning cost. If, however, you simply want to develop a quick front-end prototype or a relatively small scale application, we consider AFC a good choice.

1 2 3 Page 2
Page 2 of 3