JFC: An in-depth look at Sun’s successor to AWT
Swing into great UI development
The Java Foundation Classes (JFC) is the new set of user-interface classes Sun is creating to address developer dissatisfaction with the AWT (Abstract Windowing Toolkit). JFC is included in the JDK version 1.2. (See Resources for Sun’s Java release schedule.)
The facts about JFC
With the Java Development Kit release 1.1, Sun engineers made sweeping improvements to most parts of the Java platform and added capabilities crucial to the development of large-scale, distributed applications, most notably database development with JDBC, component architecture with JavaBeans, and distributed objects with RMI. In contrast, the JDK 1.2 has just one key theme, but it is of such central concern to Java developers that JDK 1.2 may prove to be as significant as the earlier release. The theme of JDK 1.2 is user interface (UI), and it is implemented with the Java Foundation Classes (JFC).
Preliminary versions of the largest part of JFC have been available as a separate download under the code name “Swing” for several months. Java developer Rick Frost of PeopleSoft has been experimenting with Swing and says it changed radically from version 0.3 to 0.4 to 0.5. In the documentation for version 0.5, Sun stated that “in general, all of the API in the swing, border, event, table, target, text, tree, and undo packages are frozen.” Impressed with this version, Frost says, “it looks really solid now that the API has stabilized in 0.5.” Currently, version 0.6.1, which contains the surprise announcement of a Java look and feel, is available for download from Sun’s Java site, and the final shipping version of JFC 1.1 (which works with JDK 1.1 software) will be posted for free download in January 1998. It will be included in JDK version 1.2, which is scheduled for its first beta release this month — December 1997; the final version of JDK 1.2 is slated to ship in the second quarter of 1998.
At his visionary keynote at the September 1997 SIGS Conference for Java Development in Chicago, “Emergence of a Java Reality,” Sun Java Evangelist and JavaWorld columnist Miko Matsumura treated his enthusiastic audience to a demo of “Swing,” the major component of the JFC. JFC also was the subject of two of the conference’s 60 technical sessions, and another session compared JFC with Microsoft’s Application Foundation Classes (AFC).
SIGS conference attendees had two questions about JFC:
- Does it replace the AWT?
- What’s the big deal about another set of user-interface classes?
Miko had this to say about JFC:
In order to appropriately contextualize the Java Foundation Classes (JFC), we need to understand what problems it addresses. The original method for providing GUI functions in Java was the Abstract Windowing Toolkit (AWT), which relied on native peers (Mac system buttons on a Mac, Motif buttons on Solaris, and so on) in order to achieve consistent functionality across systems. In many cases, devices such as telephones don’t have a lot of screen real estate to waste, so this peer methodology allows the mapping of telephone buttons to AWT “buttons” as needed. Thus, AWT solves a difficult and necessary problem for functioning across a variety of hardware platforms. What it does not do is achieve consistent appearance, since it is dependent on the host for its look and feel.
This [peer methodology] raised two issues: 1) The task was more difficult to implement than was originally thought, which resulted in bugs; and 2) Many people want more than consistent functionality — they want consistent appearance. The JDK 1.2 AWT should solve a lot of the bug issues, but in order to solve the problem of consistent appearance across platforms, another solution is needed.
JFC provides a way to deliver a consistent appearance by painting the same user interface (UI) on all platforms. It’s also important to note that the JFCs include rich 2D graphics support and operating system-level drag and drop. So the JFCs provide a rich UI toolkit intended for desktop-style applications and applets. The AWT continues to serve as a provider of a peer-based UI that scales across a greater diversity of devices.
JFC is built on the AWT architecture but it contains all new UI components, which are lightweight, not peer-based. Because Sun’s vision of Java is not limited to the desktop, the existing peer-based components still will be supported in future releases of the JDK, so GUI developers won’t have to convert their code to use JFC components when they begin using JDK 1.2. But one look at the examples shipped with Swing should convince anyone that the older components will not be in common use in desktop applications and applets much longer. The SwingSet sample application, included in Swing version 0.6.1 (see Resources), is a comprehensive and convincing demonstration of most of the JFC components.
JFC features
The features of the JFC include components, 2D API, pluggable look and feel, drag-and-drop, advanced text handling, and accessibility support. The following details each of these features.
Components
All AWT components have equivalents in JFC, and most of them are considerably improved. For example, Buttons, Labels, Menu Items, List Boxes, and Combo Boxes accept images as well as text. There are also many new high-level components such as table, tree, progress bar, tool tip, toolbar, tabbed pane, and slider. Many of these have been available in third-party products such as Rogue Wave’s JWidgets and KL Group’s JClass, but Sun’s implementation is as good as anyone’s. As a base set of standard components, JFC is very impressive.
2D API
The 2D API is eagerly anticipated by developers frustrated by the meager drawing capabilities of java.awt.Graphics. The API, co-authored with Adobe Systems Inc., extends the AWT to provide device- and resolution-independent graphics and imaging capabilities. It will support such features as transparency, advanced text layout, Bezier curves, and anti-aliased rendering. Sun’s Java 2D API home page (see Resources) informs us that:
The Java 2D API is a set of classes for advanced 2D graphics and imaging, encompassing line art, text, and images in a single comprehensive model. The API provides extensive support for image compositing and alpha channel images, a set of classes to provide accurate color space definition and conversion, and a rich set of display-oriented imaging operators.
Pluggable look and feel
In the early days of cross-platform software development, many companies made the mistake of porting an application without recreating the “look and feel” to match the new platform. Users scorned these obviously non-natively developed applications. Companies learned that native look and feel is a critical characteristic of a successful application. The AWT, with its peer-based controls, reflected this view of software development. But the Web is changing users’ perceptions.
Pluggable look and feel is a flexible mechanism that gives developers a choice: They can create a single look and feel on all platforms to achieve consistent appearance and behavior of an application; or, they can program applications to select a look and feel depending on the platform, in order to please users who expect native appearance and behavior. A third alternative for developers is to let end users choose the look and feel they prefer. A developer can even implement a custom look and feel across all components in an application suite or Web site.
Drag and drop
The next release of the JavaBeans component model specification, code-named “Glasgow,” includes support for drag and drop between Java and “legacy” applications. The Glasgow Draft Specification (see Resources) states:
With native-platform capable drag-and-drop, a user with a native application sitting next to a Java application will be able to drag-and-drop between the Java and native applications, and have a level of fidelity in the user gesture consistent with that of the host native platform.
A user running a Java application on Unix will be able to drag and drop to a Motif application and then run the same Java application on Windows and drag and drop to an OLE application running there. Drag-and-drop interoperability will be an important capability for acceptance of Java in the enterprise (that is, until all applications are written in Java).
Advanced text handling
At the SIGS conference, Ted Faison of Faison Computing Inc. demonstrated the sophisticated text handling implemented in the JTextComponent class, which has SGML-like capabilities. JFC applications can support rich text, including multiple fonts, sizes, colors, highlighting, and embedded pictures. Complex layout will be supported, allowing developers to assign an element to a box to constrain its position and have other text elements flow around it.
“JFC brings Java into the ’90s, in terms of its text-handling features. Now Java applications can take on the most complex situations, displaying scaled, sheared or rotated text. Text is handled much like an image, with support for such things like paths, shading, variable transparency and filling,” said Faison.
Accessibility support for people with disabilities
Software developers are slowly becoming aware of the importance of “Assistive Technology” due to federal regulations and market realities. (Broadly speaking, Assistive Technology is any technology that enables people to do something they otherwise couldn’t.) “The Java Accessibility API was designed to allow people with disabilities greater access to the world of Web technology — both at home and in the workplace,” said Jon Kannegaard, vice president of software products at Sun’s JavaSoft division. “For example, a developer can now create a single application to be used by users with and without disabilities at the same time.” (See Resources for a link to the Java Accessibility Web page.)
Moving to JFC
Although JFC is much bigger and more powerful than AWT, migration of existing code to JFC is not difficult. AWT classes like Button, Checkbox, and MenuItem have corresponding Java Foundation Classes named JButton, JCheckbox and JMenuItem. As you would expect, the JFC’s implement a superset of the functionality of the corresponding AWT classes, so migration can be as simple as changing class names. However, if you are still using JDK 1.0.2, you will have to move to the delegation event model of JDK 1.1; JFC does not support the 1.02 event model (see Resources for information about the delegation event model).
JFC uses an architecture called Model-View-Controller (MVC). This technology was invented at Xerox PARC and was adapted by Sun engineers for the JFC. In this architecture, the Model holds the data to be represented but has no knowledge of (or interest in) how it is displayed. The View observes the Model and provides screen and printer output. The Controller interacts with the user through the views of the data. In JFC, the controller and the view are integrated into a ComponentUI object.
The advantage of the MVC architecture is this separation of interface from data. For example, you can easily have more than one view of the same data — a table and a chart, for example. Also, it is easy to change the appearance of a component (by modifying the view) without affecting the underlying data. This can even be done at runtime and is the basis for the pluggable look and feel feature of JFC discussed above. Although Sunís documentation explains MVC (see Resources), the average Java developer does not need to know much about it to make use of JFC. As Ted Faison points out “The JFC MVC architecture was designed to be unobtrusive: you only need to know about it if you plan to use its features, such as pluggable look and feel.”
It is always hard for writers to keep up with a technology that is expanding as fast as the Java platform — and the Swing beta is no exception.
“The one area that is lacking is adequate useful documentation. The javadoc stuff is okay but in a lot of cases doesn’t address some necessities. This is compounded by the fact that the API has had recent substantial changes and the doc hasn’t always reflected the change. One example is how to show and dispose of a modal dialog. Parts of that documentation actually refer to non-existent methods,” says Rick Frost.
Given Frost’s concerns, it is fortunate that Swing has several complete working examples with full source code. They are currently the best source of practical information about using JFC. Sun also has begun work on adding a JFC section to the highly regarded Java Tutorial (see Resources) written by Mary Campione and Kathy Walrath of JavaSoft. At the time of this writing the tutorial is still sparse, but it has useful sections on buttons, checkboxes, labels, radio buttons, tabbed panes, tables, tooltips, and trees.
AFC vs. JFC: similarities and differences
The current controversy over Microsoft’s support for the JDK 1.1 is about RMI and JNI, which are not supported by Internet Explorer (IE) 4.0, and about changes Microsoft made to the .awt, .lang, and .net packages. Though these are critical issues to much of the Java community, Microsoft does support most of JDK 1.1. The split between the two companies will become much wider when JDK 1.2 becomes the focus of Java developers, because JFC is the major part of the update. In a recent article about the Java Lobby, “Microsoft’s ‘Java Evangelist’ responds to Java Lobby requests,” JavaWorld reports: “In terms of the request for support of the JFC and other APIs, [Microsoft Java Evangelist Brad] Merrill says Microsoft will not support the JFC, while it will consider support of future Sun APIs ‘on a case-by-case basis. We’re not going to take everything JavaSoft determines as a standard as our gospel’.”
Microsoft has its own UI class library, the Advanced Foundation Classes (AFC), which is included in the Microsoft SDK 2.01 for Java. In its attempt to win developers to AFC, Microsoft makes the following point:
AFC … has a considerable lead over JFC in time to market. It has been in developers’ hands since early this year and will ship very shortly with Internet Explorer, with every copy of Windows, and, with our recent agreement with Apple, with every Macintosh. This ensures AFC will be available on the overwhelming percentage of computers in the market. Moreover, nearly every development tool vendor has announced plans to support AFC, making it even easier for developers to target it.
At the SIGS conference, Eric Swildens of Neuron Data presented a technical comparison of AFC and JFC. According to Swildens, there are more similarities between AFC and JFC than there are differences. Both class libraries are JavaBeans-compliant and are 100% Pure Java with no underlying peer classes. Most of the components in AFC and JFC are very similar, but JFC has a couple of additional controls, namely the Rich Text control and some multimedia controls. JFC has a pluggable look and feel, and AFC has a Windows look and feel (although you can subclass components to provide your own look and feel). JFC is based on the MVC architecture, which probably helps it scale up to complex applications but which Swildens believes makes it somewhat harder to learn than AFC. Swildens found AFC container controls to be more flexible than their JFC counterparts.
Both AFC and JFC are 100% Pure Java, so theoretically whichever library a developer chooses to use, the only cost to users should be download time (if the library is not installed). Unfortunately all Java virtual machines are not created equal. Java developers must continue to take current events and company politics into account when making what should be purely technical decisions.
Conclusion
The JDK 1.1 release added some huge features to the Java platform, such as JavaBeans, JDBC, and RMI. JDK 1.2 is an equally impressive leap in functionality, mainly directed at providing a rich set of user interface tools for the development of great-looking applets and applications. Sun’s JDK engineers are clearly continuing to be innovative and responsive to the needs of the Java development community.
