In-Depth

JFC or AFC? Foundation class

• By Sally J Cusack
• July 12, 2001

Foundation classes are just what the name says, the very foundation on which information technology (IT) professionals are creating their next generation of enterprises to run business systems. Whether it is the Sun Microsystem's Java Foundation Classes (JFC) or Microsoft's Application Foundation Classes (AFC), there are three important points to keep in mind: Both AFC and JFC are written in Java; the Java language itself has only been around for two years; and the war between the two vendors here is focused on spreading fear, uncertainty and doubt (FUD) far and wide regarding the opponent's product.

What does this say to today's corporate developer? It says that the goal for next generation systems is 100% portability, and to get there, the information technology world is betting the farm on a promising but relatively untried software language. It also says that the vendors themselves are not the most reliable place to go for unbiased information when trying to make a decision in this arena. In fact, verbal assertions and accusations are being volleyed back and forth over the class foundation issues at a rapid fire rate as the litigious activities between Sun and Microsoft will decide the Java issue at large -- licensing, rights, standardization and ultimately, claims of true portability. With reference to foundation classes and the state of practice today, each vendor has its own take.

Microsoft says ...

The folks in Redmond are quick to remind users at every opportunity that the Microsoft Software Development Kit (SDK) for Java and its associated Application Foundation Classes (AFC) are a reality today -- something that Sun cannot yet lay claim to. Microsoft released version 2.0 of its SDK for Java in October 1997. The product included the final versions of Microsoft's Virtual Machine, AFC and a bridging product called J/Direct.

AFC, of course, is Microsoft's set of class libraries written in 100% Java. Redmondites are quick to point out that they wholeheartedly support Java the language; it is Java as a platform they question. AFC for Java was officially released in beta April 1997.

The key point here is that AFC, which is available as part of the SDK, is currently being shipped with every copy of Microsoft Internet Explorer 4.0 and is slated to ship with future Windows-based PCs and Macintosh systems. This gives the AFC today an installed base of thousands, but the number of people actually using this technology is far less than expected. Microsoft's hope -- and they certainly have been proven right on using this tactic in the past -- is that the majority of users will eventually use what is presented to them on their desktop as long as it is technically adequate to meet their needs.

Microsoft denies early press reports that its version of the JVM does not truly support cross-platform development initiatives. In fact, critics charge that moving from the Microsoft VM to other VMs is a complex undertaking. Microsoft contends that its VM provides comprehensive component support and allows automatic, bi-directional integration of ActiveX and JavaBeans technologies. This would allow developers to mix and match applications at will. This can be combined with the J/Direct feature, which exposes the native Win32 APIs and offers access to other DLLs, eliminating the need to write Java-aware native code wrappers.

Joe Herman, product manager, Internet platforms at Microsoft, said allegations citing AFC as Windows-specific are false. "AFC is written in Java, so to the extent that Java runs cross-platform, AFC should run cross-platform," he said. "However, everyone knows that you can only be assured that Java runs where you test it, so we've tested on Internet Explorer and Netscape Navigator for Win32, Macintosh and Unix."

"Ultimately, the only comparison that needs to be made is that AFC is shipping today," Herman said.

Sun says ...

The word that Sun would like the world to sing is "ubiquitous." This is how they position Java and all its related technologies. After suffering through some growing pains with the Abstract Window Toolkit (AWT), Sun and its Java gurus are working fast and furiously to develop a JFC that rivals Microsoft in its GUI look, feel and capabilities. The JFC released with JDK 1.1 offers a refined delegation event model, printing, clipboard support, a lightweight UI and is now 100% JavaBeans compliant.

Rick Levinson, engineering manager for JFC, emphasizes that write-once, run-anywhere is core to the design and message of JFC. Sun's JavaSoft division is incorporating JFC into the nucleus of the upcoming JDK 1.2. JavaSoft is also working closely with companies such as IBM and Netscape to release an expanded set of components written in 100% pure Java that will enable applications to be more fully integrated into native environments. These new high-level components are slated to be available on all platforms as part of the standard Java platform, thereby eliminating the need to download extra classes. Additionally, JavaSoft maintains that all new JFC components will be both lightweight and peerless. This overcomes many of the limitations found in the AWT, where peer-based components cannot be easily extended or overwritten. The newer component models in JFC will be designed to enable customizable "look and feel" development without having to rely on native windowing systems or adding systems overhead.

Future JFC aficionados can also look forward to the release of Swing, a set of user interface components developed to run on top of AWT. Swing will be delivered as an unbundled set of class libraries and insure backward compatibility. According to Levinson, it is 100% pure Java, there is no C code and no Java code goes outside of the legally designated Java APIs. According to Sun officials, JDK 1.2 is scheduled for release Q2/'98. The Swing components will be shipped separately as a separate download in Q1/'98. It will be bundled with JDK 1.1 for existing applications.

Is one really better?

Of course, the opposing sides are happy to point out what they consider to be the other's weaknesses. Microsoft contends, with some truth, that today's JFC is not as functionally rich from a GUI perspective as the AFC. For example, today's JFC supports a handful of font selections while AFC offers hundreds of fonts and extended backgrounds. However, Sun and early JFC users say that JFC will soon be leap-frogging ASF or at least, achieving parity with it on the GUI and screen events levels.

At the top of the list are the cross-platform issues. Microsoft says there are no issues, Sun says with the MVM, there are portability problems. So where does one go to find real answers?

"The whole Java write-once, run-anywhere is a myth until you have tested everywhere, or at least a good sample of where you need to be," said Eric Carlson, chief technology officer at Silknet Software Inc., Manchester, N.H. The two-and-a-half-year-old company focuses on enterprise application design optimized for the World Wide Web. His product, a customer service application, is centered on a three-tier architecture utilizing a thin browser-based client to allow easy access to the application's capabilities. Silknet is in the early stages of AFC development.

Silknet's customer service application built on top of the Internet using distributed object technology (in this case, DCOM) is available on MS Windows and NT platforms. The Silknet software uses thin marshalling capabilities for invoking objects on a Unix server and uses a Java proxy to call the business objects on an NT server. Requesting a URL on Solaris, for example, can create a Java component (or proxy) which then can invoke business objects via sockets. This gets marshalled over the Unix environment and scripted into HTML. The services themselves are actually executed on the NT server.

According to Carlson, there is some functionality that needs to be constant on both sides of the equation and requires a Java solution. It is no secret that the AWT components are lacking in functionality, and therefore Silknet is looking at AFC. Characterizing AFC as "very easy to use," Carlson added that the performance is much better than he anticipated. Additionally, he echoed previous comments from the development community which praise the richness of the AFC widget set. Regarding the JFC side of the equation, Carlson acknowledged that they, too, are creating a rich widget set. However, since the product is not released yet, "the jury is still out."

"All of the base components, which we typically use on a Windows platform, work well," he said. "The AFC controls rely completely on Java. Portability is an important criteria for our success, so we will test this ourselves." Silknet will be testing the AFC-based software against various browsers and Virtual Machines (VMs). Theoretically, the software should run on any JDK 1.1 compliant browser. However, Carlson's advice for others looking to implement this software is an emphatic "don't believe everything you read, test it yourself. And don't believe the vendors, either."

Offering more JFC-oriented point of view, Ron Repking, principal of ISA Services Inc., Chicago, has been working with Java since its inception. In fact, ISA Services, an enterprise object-oriented consulting company, has participated in Sun's Java Advisory Council. Repking and his team have worked with the first release of development release of JFC, which came out in Spring 1997.

ISA has developed its own Java framework, dubbed the Athens Architectural Component. This is a 100% pure Java product that can be integrated with Corba. Comprised of eight packages, it offers a variety of services including configuration, logging, application events, online help and JDBC connectivity. All of these services are designed to utilize
the World Wide Web. Repking recalls that ISA was using a sort of pre-beta version of JFC when it first came out, and it was applied to an application for a small company that sells membership for non-profit organizations.

The porting was relatively simple, requiring one person working in off hours for a couple of weeks. "The process mostly involved name changing," says Repking. "The application itself had been written in JDK 1.1, and we ported one component at a time. It is pretty stable at this point, and the customer will be using it soon." All of ISA's work for this project was done on a WinNT platform.

When compared with AWT, Repking notes that JFC has a different look and feel and has its own model for taking on a Windows 95 or Netscape appearance. Minor color differences in controls aside, Repking thinks probably the best aspect of JFC is the Model View Controller (MVC). "The MVC allows you to use your controls with real objects instead of with strings. The model is separate from the domain and the controller ties the two together. We didn't have to do the conversions." He summarized the JFC as "another GUI widget toolkit, except it's free and it provides a lot of added functionality."

John Zukowski is a software mage (instructor) at the MageLang Institute in San Mateo, Calif. He teaches students from all walks of information systems (I/S) life, from small companies to large multinational corporations. People come to learn everything they can about the latest Java technology. The Institute offers a variety of classes, ranging from the C programmer who needs to know the basics of object-oriented design to those with a Java background who are looking to refine and leverage the latest Java technology.

He encourages developers that, while keeping in mind that JFC is not released yet, they should still download the early access version and play with the code. There are tutorials available and many free online resources available in the Java community. Admitting that he has "avoided AFC," Zukowski said that JFC is going to offer flexibility far beyond that of AWT.

"AWT is everywhere. It seems to go to the lowest common denominator approach. For example, if you want to create a button in AWT, you can only do it with text," he said. "With JFC you can have seven or eight different images on a button depending on its state. The image can be animated, not just static. This gives you flexibility based on state-related
information."

Indeed, AWT seems to be everywhere in the Java environment. Microsoft publishes voluminous information on how to use AFC components in AWT applications. But with to the already available AFC and the soon-to-be-available JFC, most features and functions seem to be at parity.

While each vendor likes to shoot at the other on issues such as platform support and JDK 1.1 and 1.02 support, users must remember the goal of both teams (supposedly) is portability, and ultimately, performance. There is no getting around the central issue that Java the language is interpreted, thereby making it slower by nature than its compiled counterparts.

Aris Buinevicius, co-founder of Stingray Software Inc., Morrisville, N.C., says his company's biggest QA nightmare is the cross-platform issue. Stingray produces C++ components for software developers, and for the past year and a half has been moving steadily towards providing them in a Java environment. "Working around the various JVMs has been our biggest development nightmare. We believe the Sun portability labs will help, as will the next release of the JDK," he said.

However, if the JVMs continue to be incompatible, client-side development will be impossible for Stingray. For simple application development, the work arounds are okay, but many of the Stingray clients are getting down to the nitty-gritty cross platform issues. The company has approximately 6,000 customers in the C++ world.

Acknowledging that native executable speeds are impossible with Java, Buinevicius said there are different tweaks for enhancing performance. He believes that the JIT compiler and Sun's upcoming Hot Spot technology will help.

According to Sun, the "classic" VM will eventually be replaced by the HotSpot VM. The latter is targeted to deliver self-adaptive optimization and a host of other things designed to speed Java performance. It will reportedly include in-line code to reduce overhead associated with object allocation, dramatically increase thread synchronization performance, use memory compression for loaded classes, and do a much better job of garbage collection via the use of different algorithms for short-lived and long-lived objects.

For users of the Java Native Interface (JNI) for native methods, it will be relatively easy to plug in the HotSpot VM. Later on, however, for the multitude of users using other VM implementations such as Microsoft's pluggable upgrades to the HotSpot VM and its associated benefits, it will be impossible.

So where to go? Microsoft or Sun? AFC or JFC? Certainly the MVM and its associated AFCs have the largest foothold in the installed base today. Yet the allure of Sun as the developer of Java and purveyor of all true Java implementations has fired the public imagination.

MageLang Institute's Zukowski has some advice which can be applied to all Java uses everywhere. Albeit the technology is only two years old, he recommends getting out there and "getting ahead of the curve." This includes reading some of the books now available for beginning and more experienced Java programmers, downloading the foundation classes and playing with the code and taking advantage of free online resources. He points out that Java is fast becoming the language that colleges and universities teach freshmen.

This is probably the best time for developers to sit back and educate themselves on the basics of Java, its promises and its potential pitfalls. For those that have already entered the AFC or JFC camp, it looks as if each vendor is ready and willing to do what it takes to make its constituents happy. As far as a long-term prognosis for benefits one might hold out over the other -- the jury is definitely still out.