[Editorıs Note: This new column by veteran developer Nelson King explores emerging products and technologies for building enterprise Internet, intranet, and extranet database applications. Net Developer will appear bimonthly and alternate with Tom Spitzerıs Component Assembler column, which is also bimonthly.]
"Look at this, will ya?" Thatıs Mike; heıs been a Java programmer for a while, and heıs helped me a lot while I was preparing to do Java applications for the Web. He pointed to his monitor, where I expected to see a Java applet do some dazzling graphics. Instead, I was looking at code that uses foundation classes. "See that? FXSystemFont. Iıll bet thatıs one of those pieces that failed the Java compatibility test."
I donıt know if it is one of the pieces or not. As Iım writing this column, Sun Microsystems has just sued Microsoft for, among other things, failing tests in the Java Compatibility Kit (JCK). Itıs possible that elements of Microsoftıs Application Foundation Classes (AFC) that are Windows-dependent ı such as a call to get the system font ı might have failed the test of portability. I donıt know, because at the moment Sun and Microsoft arenıt sharing details of the suit.
"Bet they kiss and make up in less than three months," said Mike. I replied, "What makes you say that? Apple and Microsoft were locked in court for a long time." Mike looked at me with a touch of mock disdain, as good programmers often do when they think something is obvious. "Sun needs Microsoft," he said."So did Apple, but it took time and the wisdom of Steve Jobs for them to figure it out."
Maybe a cynical sense of humor is what it takes right now. Itıs also a good time to start a column about developing software for the Internet, intranets, and extranets. The situation has prodigious potential, but itıs also a mess ı like a rickety truck moving at 100 clicks with stuff spilling out the sides left and right. Yesterday HTML ruled, today itıs dumped and replaced by Dynamic HTML (DHTML). I canıt promise you that I can always make sense of what is happening, probably because in some situations there isnıt any sense to be found. I can promise, however, that Iım going to keep an eye on a number of topics that excite, intrigue, bug, and scare developers. Java is going to be in and around center stage most of the time, but lots of other things are involved that arenıt specifically Java, for example, distributed objects (CORBA, DCOM, and the like).
Iıd originally thought of calling this first column, "Class Wars." Then I could use sentences like, "Java: The War ı Where the front lines are browsers and the trenches are the foundation classes." Bad metaphor. Java isnıt a war; itıs not even a religious experience. Both war and religion metaphors are convenient ı and will be used endlessly ı but they are trite and not very accurate. In wars, people die. Likewise, you might believe in Java with passion; I do, but so far no epiphanies, visions (the Pearly Gates?), or visitations.
However, I wonıt (and canıt) avoid controversy. In the computer industry, if itıs important, itıs usually controversial. And Java is certainly important. Most of the time Iım content to deal with Java as a programming language, but I realize that there is probably more at stake than a somewhat immature language thatıs very good for developing Web and intranet applications. Foundation classes ı a purely programming subject if there ever was one ı also happen to be embroiled in the Microsoft vs. The Rest of the World Java controversy. Too bad, but there we have it. Letıs dive in.
If youıre just starting to learn Java or other object-oriented languages, you may not have directly encountered foundation classes. In fact, if youıre using one of the commercial application development systems such as Symantec Visual Cafı or Borland JBuilder, you may not even know the foundation classes are there. They can be obscured by the visual programming environment, at least until you have to track down something that doesnıt work or want to add a feature that isnıt in the classes.
Itıs easy to be overly impressed with the "foundation" moniker. These Java classes come in packages (libraries) written and assembled by vendors to simplify or enhance your programming. However, they arenıt that fundamental; that is, they are not part of the java.lang package. In fact, most of them are built on (or around) the Abstract Windowing Toolkit (AWT), which itself extends Java to provide important user interface objects and other visual features.
The foundation classes fill in the gaps and overcome the limitations of AWT so you can create "modern" user interfaces that people expect. Primitive Java makes primitive-looking screens (for example, mostly text). AWT improves the screen graphics but lacks certain graphical features and sophisticated interface components like tabbed dialogs. Of course, what the vast majority of users are expecting are the elements of the Windows user interface, and therein lies the origin of the controversy.
The first foundation classes off the block came from Netscape in 1996. Theyıre usually called Internet Foundation Classes (IFC), although sometimes theyıre referred to as Netscape Foundation Classes (NFC). IFC was based on the object model used by Nextstep (from the NeXT company, bought by Apple, which led to its reacquaintance with Steve Jobs).
What Netscape (and Sun) wanted in IFC was the functionality of typical Windows controls (the Microsoft term for user interface components), but with a more generic look and feel. At least in the terms of user interface design, this leaves the path open for Java to go its own way ı mostly away from Windows. Naturally, this is anathema to Microsoft. Seeing that AWT was, by any standard, deficient for building complex user interfaces and that Netscape was tailoring its IFC to the Netscape browser, Microsoft launched its own foundation class effort. This first appeared in April 1997 as the Application Foundation Classes (AFC).
Coincidentally, on the same day that Microsoft announced the AFC first release, Sun, Netscape, IBM, and Apple announced they were building the Java Foundation Classes (JFC). Later, in July, the first beta of JFC appeared and since then has been incrementally improved and expanded. The final version of the JFC was scheduled for the fall of 1997, but was put off to match the delivery of JDK 1.2 sometime in the first quarter of 1998.
You can see the competitive pattern here. I was at both the Java One and the Software Development ı97 conferences in San Francisco in April 1997, where Microsoft announced AFC and Netscape/Sun announced JFC. You could feel the static in the air. In fact, Microsoft had a big booth that straddled the Java One and SD97 exhibition spaces ı a nice piece of symbolism.
My impression is that Microsoft wanted to keep the AFC wholly within Java. Itıs written in Java and, barring glitches that are supposed to be fixed, should run across operating system platforms. (This is not what Sun contends.) AFC presently has about 30 classes organized in two main areas of functionality. One, in the Java package ms.com.ui, delivers a set of user interface components (controls). These conform to the JavaBeans model (not ActiveX). The other package, ms.com.fx, enhances the general graphics capabilities of Java. (You can find the AFC packages at www.microsoft.com/java/resource/afc.htm.)
The various UI classes (for example, UIText and UIGraphic) are generally wrappers for AWT classes. The basics include improved labels and graphics for Java applets (UIStatic). There are improved screen controls: UIEdit, UIButton, UICheckButton, and UIList. The AFC doesnıt have all the controls found in Windows 95, but the selection is better than AWT, and presumably will be updated by Microsoft as Windows 98 appears.
More sophisticated components include UIMenuList and UIBarBand classes, which make it possible to implement a menu system in an applet (odd as that may sound). There is a decent tree display control (like Windows Explorer), UITree, and UIStatus for the ubiquitous Windows status bar. Because AFC ships with Microsoft Internet Explorer 4.0, there are also controls aimed primarily at the Web, such as UIMarquee, which does the scrolling banner thing.
The graphics package of AFC is not spectacular, but it does enhance AWT and makes the classes behave more like their standard Windows counterparts. For example, it makes it possible to access the Windows fonts currently in use (hence the perceived all-too-tight binding with the Windows environment).
As I worked with them, it seemed that the classes in AFC were a straightforward attempt to translate Windows controls and their conventions into true (I wouldnıt dare say pure) Java. AFC should not be nearly as offensive to the Java cross-platform crowd as Microsoftıs JDirect, which provides a Java wrapper class for Windows APIs. I was particularly impressed with the ability to navigate the entire GUI using the keyboard and that many of the controls hot track, meaning they light up as the cursor passes over them. This puts the feel of this library clearly in line with IE 4.0.
On the surface, JFC appears to be more ambitious than AFC, which may account for its somewhat delayed completion. Itıs also the product of a programming consortium, with members from Netscape, JavaSoft, IBM, and others. Multivendor teams make my hair follicles twitch (all 10 of them), but I suppose the competitive pressures in this case are enough to keep them focused. The early release, which appeared in midsummer, is promising.
The centerpiece of JFC is the "Swing Set," the UI component classes that supercede those provided by AWT. When the Swing component set is complete, it will not only include a collection of 100% Java versions of existing AWT components (such as Button, Scrollbar, List, and so on), but it will also include higher-level components such as TreeView, ListView, and TabbedPane.
The most unusual aspect of JFC is the UIFactory class. When instantiated, this object generates all of what is called the "pluggable L&F" (look and feel). Every component can be associated with a single user interface, and each UI is defined and implemented through the UI factory. Translated, this means that the JFC is truly independent of the OS (namely Windows) and can be used to define its own user interface appearance at runtime ı a very useful feature under some circumstances. The current beta of JFC is at developer.javasoft.com/developer/earlyAccess.
I wish I could say more about JFC, but itıs still too early. There are bugs and strange behaviors that make it difficult to evaluate most of the classes objectively. This is the position for many independent software vendors, who are trying to decide which foundation classes to support. You might be interested in just whoıs signing up with what:
Asymetrix Learning Systems Inc.: Supercede Java Edition ı AFC
Bulletproof Corp.: JDesignerPro ı AFC, JFC pending
KL Group: JClass BWT ı AFC
Microsoft: Visual J++ ı AFC (of course)
ObjectShare Inc.: Parts for Java ı AFC
Powersoft: PowerJ ı AFC, JFC pending
Symantec: Visual Cafı ı IFC, JFC pending
Visual Numerics Inc.: JWAVE ı IFC
Borland: JBuilder ı AFC and JFC
IBM: Visual Age for Java ı AFC, JFC pending
The list is obviously incomplete and there is another approach, which might be characterized by quoting Shakespeareıs Romeo and Juliet: "A plague on both their houses." Using this approach are the companies that, like everybody else, decided AWT wasnıt enough to produce a decent user interface, and finding either the politics or the implementation of other foundation classes a deterrent ı they wrote their own. Of course, most of them are too diplomatic to say that they wonıt ever use AFC or JFC.
I had the opportunity to talk with someone from one such company, SilverStream Software Inc., a startup with a very comprehensive Java application development product and a powerhouse development staff. Arny Epstein, SilverStreamıs chief technology officer (formerly chief architect at Lotus), said they began with what was available at the time, Netscapeıs IFC (AWT was never in question), but quickly decided that it didnıt fit the bill. So they wrote their own set of foundation classes that in some ways are more sophisticated than those now offered by either AFC or JFC. And thatıs the point. I wonıt say that Microsoft or Netscape/Sun are writing to the lowest common denominator, but donıt expect great sophistication in these foundation classes, and donıt expect it to be easy to subclass them.
This reminds me of an old issue in object-oriented programming: whether to buy or build a class hierarchy. Obviously, with Java you get a set of native classes, and you start there. If you build your own "foundation classes," you have a major advantage in knowing whatıs in them and how they can be subclassed. But itıs a lot of work. If you acquire your class libraries from somewhere else, you save enormous amounts of time, but it may be difficult (or impossible) to know how the classes are constructed, which may lead to inheritance problems for debugging and subclassing. Come to think of it, there was a similar problem with function libraries, too.
Epstein made a good point about adopting foundation classes: They tend to enforce a particular programming model. Netscapeıs IFC is browser-oriented, Microsoftıs C++ Microsoft Foundation Classes is wizard-oriented, AFC is Windows UI-oriented, and so on. For some companies, these models may not be appropriate ı or simply donıt allow enough creativity.
I like SilverStreamıs pragmatism, and Iıve heard other small Java vendors say similar things. They canıt afford to indulge in the hype promulgated by Sun, Microsoft, and Netscape (with a few buddies). Iım often nonplussed by normally rational programmers who use superheated language to say how much they hate or love Microsoft, Unix, or anything else. Itıs as if theyıve completely forgotten that in a capitalist economy, businesses are expected to be ruthless competitors (short of significantly damaging the company by reputation). Why they think Microsoft shouldnıt defend its operating system hegemony is beyond me. It also seems to me that Sunıs stick-in-the-eye approach ı threatening the end of Windows with new NC and other Java operating systems ı is more than a little disingenuous. I donıt recall hearing Sun saying that itıs time to rewrite Solaris in Java.
In any case, youıll have several choices with foundation classes for Java, or at least in the choice of class libraries. There will be independent libraries, libraries of freeware, libraries from Microsoft, Sun, and Netscape, and anything you can write yourself. Managing these libraries isnıt going to be easy, but then even object-oriented programming has its weaknesses.
It would be nice to see a language with a universal implementation, but historically compromises between performance, features, and generic behavior have been the rule. I suppose there are those who believe that Java could be, should be, that unified language. However, speaking with the pragmatic view, if we end up with only two versions of Java and two sets of foundation classes, Iıd say weıd gotten off lucky.
My friend Mike says that heıll pick and choose from the best of breed ı or write his own. Iıd like to hear your opinion about building vs. acquiring foundation classes. (You can skip the flames against JFC, IFC, or AFC.)
What did you think of this article? Send a letter to the editor.