JFC and AFC debate creates confusion, demands choices

Developers wade through issues created by different foundation classes

Developers tracking the split between Microsoft and Sun Microsystems over Java can add another front to the battle -- foundation classes. Microsoft has AFC that are now shipping in early production form. Sun, Netscape, and IBM have collarborated on JFC, which is about to ship to the public in beta version. With the 1998 shipment of JDK 1.2, JFC will be defined as part of core Java, making it incumbent upon Microsoft to include JFC with its Java virtual machine. Like RMI and JNI, Microsoft says it has no intention to do so because its technology is better.

The good news for developers is that it is far easier to work around the absence of the expected set of foundation classes than it is to overcome crucial middleware that is missing. The bad news is that the goal of "write once, run anywhere" continues to take it on the chin -- not due to the failure of the technology, but rather due to the inability of Sun and Microsoft to bury the hatchet anywhere but squarely in the back of their antagonist.

Recent history

The first release of Java contained the Abstract Windowing Toolkit, or AWT. In retrospect, even Microsoft and Netscape agree it was inadequate. Its poor performance was complemented by a cumbersome and overly restrictive event model.

One of the new features hailed in early releases of JDK 1.1 was a completely rewritten AWT, including a fundamentally different delegation event model. The new AWT boosted performance and improved flexibility, advocates said. Even so, Netscape was moving forward with its Internet Foundation Classes (IFC), and in January 1997, Microsoft announced it would develop AFC -- Application Foundation Classes.

In March, Microsoft began letting companies get a look at AFC, and in April it released an early version to developers. About the same time, at the JavaOne developers conference, Sun and Netscape announced that they would jointly develop Java Foundation Classes (JFC) with IBM and others, rolling in generous portions of the IFC.

Ever prickly, Microsoft takes offense that Sun and Netscape embarked on JFC without seriously considering adopting AFC, or using it as the point of departure for JFC. The result, says Joe Herman, Microsoft product manager in the applications and Internet client group, is that AFC is real today and has a six-month engineering jump on JFC.

Sun has always been very receptive to working with and adopting Java technology from other firms, responds Rick Levenson, an engineering manager within Sun's JavaSoft division, and the person responsible for JFC, among other projects. "Perhaps if their licensing agreement would have allowed us to look at the code without tainting our whole development effort, we could have taken a look," but that was not what Microsoft offered, says Levenson.

More than just UI components

One of the misconceptions regarding AFC and JFC is that they are merely interface widgets. This is not strictly the case.

The two major pieces of AFC are the user interface classes (UI) and the graphics classes (FX). The UI classes extend the AWT with about 30 widgets, while the FX classes add font, printing , and color capabilities, including brushes, pens, textures, fills, and palettes.

Microsoft is also delivering a set of distributed computing services under the name AFC Enterprise Libraries. AFC Enterprise Libraries are Microsoft's alternative the Sun's Enterprise Java initiative. These enterprise classes are separate from the AFC GUI classes and not included in comparisons with JFC.

Most of the analysis and discussion of JFC has focused upon Swing -- its package of user interface components. It is this set of classes that has gone through several developer releases and will soon ship as a supplemental package for JDK 1.1 users and developers.

The other major piece to JFC is 2D graphics support. Graphics support requires some native code, says Levenson, so the 2D graphics library must await JDK 1.2. A beta release of JDK 1.2 is slated for December, with the production release expected during the first half of 1998.

Drag-and-drop functionality and accessibility features for the physically challenged are also part of both AFC and JFC.

JFC and AFC compared

Bracketing both political issues and growing concern that confusion will slow Java's momentum, developers are left to compare the relative merits of the foundation class sets. For better or worse, there appears to be no clear winner when AFC and JFC are compared within this narrow context.

"Component for component, they match up fairly evenly," says Bill Lobe, a senior engineer with Morrisville, NC-based Stingray Software. "From a functional standpoint there simply are no overwhelming differences that would make a programmer shudder -- no overwhelming reason to choose one set of components over another," says Lobe.

Both AFC and JFC do a fairly good job of supplying the basic user interface components and functionality. That includes components such as radio buttons, check boxes, label controls, combo boxes, list boxes, text controls, and edit controls. They both also support menus, tool tips, scrolling panels, tool bars, progress bars, tree controls, tab panels, and drag-and-drop functionality. Additional similarities include announced support for JavaBeans, support for the delegation event model of AWT 1.1, printing support, desktop color integration, mouseless operations, and accessibility support.

Now that we've noted the many similarities, let's consider that AFC and JFC have very different historical roots. Microsoft's AFC were developed from Microsoft Foundation Classes (MFC) in its C++ development environment. Sun incorporated IFC from Netscape and used Netscape engineers in the process. While representatives from the opposing companies participated in advisory panels on the competing foundation classes, engineers implementing those classes were isolated from their competitor's work.

There are, therefore, noticeable differences.

Different architecture

One over-arching difference, says Eric Swildens, director of software solutions for Neuron Data, is the fundamental architecture. While both have a lightweight or peerless architecture and both support the delegation event model, the JFC UI architecture is based upon models and views, while the AFC interface architecture is component driven. In short, while the class sets may have pretty much the same components, using JFC may seem like overkill for simple projects, while AFC may seem inadequate for more complicated enterprise-class application interfaces, he says.

With the model/view approach of the JFC, containers such as list boxes have a renderer interface to display items and an editor interface to manipulate them. A single component may thus render multiple items and the view is separated from the data model.

By contrast, a list container in AFC is simply a panel that stacks up the contents vertically. AFC containers will generally allocate far more controls than comparable JFC containers.

In general then, AFC APIs are simpler, smaller, and more straightforward. As interfaces grow in size, however, the more complex API of JFC is likely to deliver more scalable interfaces and deliver greater programming ease. Using model/view allows you to easily build complex interfaces that map a user interface object to an outside data structure. AFC requires developers to ensure the user interface is constantly updated to keep it synchronized with the outside data model, says Swildens.

Swildens notes, however, that the JFC does provide a simple interface to many of its classes so that a developer can make a list of items without having to separate a model and a view of the data. That said, developers will still have to deal with methods supporting more complex behavior.

Other differences

There are a handful of items that set JFC -- at least the Swing subset of JFC -- apart from the UI components of AFC. Perhaps the most significant is Swing's pluggable look-and-feel, says Lobe. "If a developer is concerned about the look- and-feel of their application and does not want it to be Windows, then JFC is a better choice," he says. JFC has two dynamically switchable look-and-feels -- Windows and Solaris -- and also provides the ability to extend base styles, or to create a completely customized look-and-feel. AFC does not offer equivalent flexibility.

Swing also has an interface for a graphics debugger. The cross-platform look and behavior of graphics varies from machine to machine, so a graphics debugger can be an important benefit. The graphics debugger slows down the graphics and shows a developer the order in which everything is drawn, says Lobe. There is a demonstration of the debugger in the Swingset demo available on Sun's Web site.

Lobe contends that JFC provides notable differences in subwindows capabilities and management. Frame subwindows provide smaller windows that can float around inside a main window. They can be layered, closed, minimized, and maximized.

JFC also has a layout manager based upon springs and struts. This enables a developer to, for instance, set up a layout that uses springs on a component to dynamically resize margins, or spacing as the window is resized, or struts to fix those dimensions.

Experienced Windows developers will naturally find that AFC does a much better job of providing components and behaviors with which they are familiar.

That includes band box controls, like those at the top of Internet Explorer, which are filled with buttons or controls that can be slid back and forth, and floating or repositionable menus. Marquee controls handle scrolling text or graphics across the screen in a variety of ways. Many pre-built dialogs such as font choosers, color pickers, message boxes, etc., are provided. Many of these dialogs were modeled after those found in the Microsoft Foundation Classes. And AFC has wizards, which are tabbed dialogs with next and previous buttons, that can lead a user through a sequential task.

JFC does have repositionable tool bars, says Lobe, but not menus. He notes that Sun plans to add more pre-built dialogs into JFC.

One fundamental difference for AFC is its support for the AWT event model in JDK 1.0.2, in addition to the delegation event model of AWT in JDK 1.1, which both JFC and AFC support. This may appeal to developers over the short-term because many Java VMs have not yet stepped up to support JDK 1.1.

A matter of purity

Microsoft appears to be having a tough time with the Java community. On one hand, spokespersons such as Herman emphasize that its work with AFC was pure Java code and will thus deliver the cross-platform promise of Java. On the other hand, senior Microsoft personnel often deride Java, and the firm's Java section of its Web site proclaims an "independent" report on Microsoft's Java strategy that concludes that the write once, run anywhere promise of Java will never materialize.

Herman describes Microsoft's Java strategy as three-fold: to deliver a Java-only virtual machine, to deliver value-added but platform-neutral enhancements, such as AFC, and then to deliver a layer of Java code that fully exploits the Windows operating system, such as J/Direct.

"Pure Java is just not a term that we use," says Herman, but quickly underscores the point that his firm's "platform-neutral enhancements" do not use proprietary extensions.

Herman says Microsoft considers 100% Pure Java a marketing campaign, and asserts that Sun would never allow important Microsoft technologies to pass the certification process.

Many developers disagree.

"It seems clear that Microsoft is testing the waters to see what strategy can successfully derail Java," says Steve Adler, director of software development of Carlsbad, CA-based Triteal. "First they love it and embrace it, then they hate it and reject it, and now they want to pick the parts they like and throw the rest away."

While Windows PCs are very important to Triteal's business, the firm's desktop software leverages a single code base over many platforms, including NCs.

"One of the things we are counting on, and we've been doing Java development for over two years, is Java being the same everywhere. That is one of the main value propositions for Java," says Adler. "AFC is simply not a viable solution for us. To get to where we want to be on the desktop we need a lot of the functionality that is in JFC. And we are partnering with companies like Wyse Technologies that produces an NC that simply will not have AFC on it," says Adler.

Triteal recently took a look at AFC, and Adler says some capabilities are interesting, such as being able to take advantage of native Windows capabilities. If you want to write to Windows, however, "why not just write stuff in Visual Basic or Visual C++? If I'm only going to use Java just for Windows it doesn't make sense for me to be writing in Java in the first place," he says.

"We would like to be able to run with any JVM on any platform, but until Microsoft decides that it is going to implement the specification as written, that simply isn't going to happen," says Adler. "We will just have to specify that a non-Microsoft Java VM is required on Windows."

1 2 Page 1
Page 1 of 2