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
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.
AFC versus JFC
|Written in Java
|Delegation Event Model
|Desktop Colors Integration
|Extended Font Support
|* An early release available
Source: Microsoft, Sun
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
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
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.