[ Go to August 1997 Table of Contents ]
A Microsoft product manager was in my office with his trusty PR sidekick, showing me a demo of Microsoft's new Application Foundation Classes (AFC) for Java. As we waited for his laptop to boot and the demo to load, we got to talking about the issues facing Java programmers. "When do you go to native code?" I asked. I was thinking about how hard it is to get Java code to run fast, and how time-consuming it can be to port native code among platforms. "Before I say what Microsoft thinks, what do you think?" "If you're writing for a single platform and want the best performance, as soon as possible; if you're writing for portability, as late as possible." The two of them broke out laughing. "What's funny about that?" It took them a moment to calm down enough to answer. "Oh, you just summarized our Java strategy white paper in 25 words or less." What's new in Java? A lot's happening with Java. Sun released version 1.1 of the Java Development Kit (JDK), with JavaBeans support and a bunch of new classes. Versions 1.2 and 1.3 are scheduled for release later in the year. Netscape has released a set of classes, IFC (Internet Foundation Classes). Microsoft is about to release AFC. Symantec now features new classes in Visual Cafe, and there are also new classes in Visix's Vibe. Not to be left out, Vision Software includes new classes in JADE. I'll resist the temptation to turn that into a good news/bad news joke. Like most emerging technologies, Java wasn't quite finished when it was released. The standard visual object classes in Abstract Windowing Toolkit (AWT) were so lacking that AWT quickly became Awkward Widget Toolkit or Awful Windowing Toolkit in a lot of people's minds. Most Java applets are downright ugly, not to mention slow, compared to native Windows applications. That doesn't have to be the case, but it is. There were other early problems, too. In JDK 1.0.2 there was no standard way of using Java classes as components; Java applications were limited to five fonts; Java had no real model for printing; and Java had no good way to access databases. JDK 1.1 addresses the components (Beans) and database (JDBC) problems, and later releases should solve the font and printing problems. What happens when holes exist in a popular standard? A lot of people rush to fill in the holes. Some do it out of necessity; some desire to capture and co-opt the standard; and some just do it for the money. A lot of new tools are coming out that take advantage of JavaBeans. Beans are Java's standard software component APIs. They expose properties and methods, and fire events, much in the spirit of ActiveX controls. Properties have get and set methods, whose names are normally constructed from the property name. A Foregound property that represents a Bean's foreground color would be read by calling Color getForeground() and updated by calling void setForeground(Color c) . Bean methods are just ordinary public Java methods. Events resemble Windows or ActiveX events; a revised model for handling events in the 1.1 version of AWT supports registering "event listeners" with "event sources" and eliminates the need for huge switch statements to handle events. A Bean carries with it information about its interfaces. When you add a Bean to an application builder, the Builder introspects on the Bean to discover its properties, methods, and events. Introspection has two phases: In the first phase, the Builder reflects on the Bean's public methods; in the second phase, the Builder applies design patterns to deduce the properties and events from the method names. For instance, a Builder that finds Color getForeground() and void setForeground(Color c) methods would deduce a Foreground property of type Color. Beans can supplement the Introspection process by implementing explicit EventInfo, MethodInfo and PropertyInfo methods, but in most cases these won't be necessary. It's the interaction with application builder tools that makes Beans really cool. Environments like Delphi and Visual Basic have long given us proprietary drag-and-drop components with properties and methods, and recently both of these environments have been enhanced to work with ActiveX components. JavaBeans are drag-and-drop components for any Beans-aware Java application builder on any platform. I recently downloaded my first set of JavaBeans, a beta of JWidgets 3.0 from Rogue Wave Software (http://www.roguewave.com). I'll know more about how they work when I have a true Beans-aware Java development environment running. Microsoft SDK for Java 2.0 I do have beta compilers and classes for JDK 1.1, in Microsoft's SDK for Java 2.0 and in Sybase's PowerJ. You can download Microsoft's SDK from http://www.microsoft.com/java/. It contains pre-release versions of the AFC classes, improved implementations of the standard classes, a vastly improved JIT compiler (used to speed up Java code at run time) and a bunch of new tools. You can use it to upgrade your Visual J++ installation if you wish, but it won't magically turn it into a drag-and-drop application builder. The two major pieces of AFC are the user interface (UI) classes and the graphics (Fx) classes. The UI classes extend AWT, adding about 30 widgets. Think about the sorts of UI components you find in Windows now, and you'll be on the right track for the UI components in AFC: tabbed dialogs, list views, tree views, splitters ... The Fx classes also extend AWT, adding the sort of color and font capabilities you find in Windows. Fx extends Java's simple color model to brushes, pens, textures, fills and palettes, and extends Java's five fonts to arbitrary outline and downloaded fonts. The pre-release AFC classes don't really support printing, but the final classes should. I'd be concerned about the size impact of using AFC classes in my own applets, but Microsoft has a solution. It will widely distribute AFC this summer as part of Internet Explorer 4.0. People who don't have IE4 will be able to download a CAB file of AFC classes. I have no real idea at this point how big it will be. Java vs. C++ I've come to have mixed feelings about Java, especially as compared to C++. In some ways, Java gives me a lot of pleasure: Things are often simple and clean in Java, and less so in C++. In other ways, though, Java drives me up a wall. Often, it's the same features that give me pleasure that drive me up a wall. Let me explain. Java doesn't have or need pointers. That makes Java much easier to read and write than C++. It also makes Java a lot slower than C++ for problems that lend themselves naturally to pointers. For instance, using pointers is the most efficient way to address elements of a spreadsheet. Recalculating a spreadsheet in Java will probably never compete with recalculating a spreadsheet in C++. Think about what that means for Corel's quixotic effort to produce an office suite entirely in Java. Java doesn't have or need a way to explicitly free a block of dynamic memory, because it has a garbage collector. That makes it impossible to write Java code that leaks memory. It also makes it difficult, if not impossible, to write Java code that uses memory efficiently. As a programmer, you're completely at the mercy of the garbage collector implemented in the Java Virtual Machine (VM). You can force garbage collection by calling system.gc, and you can improve things immensely by being careful about the scope and lifetime of your variables. The real problem is that the quality of Java VMs varies considerably: A VM with inefficient garbage collection may need 32MB of RAM to run a Java program that a better VM can run in 16MB of RAM. There are more than 40 Java VMs in use. Testing on all of them is a nightmare. Java has lovely implementations of objects, classes, inheritance and exception handling. It requires you to use them. You can write C++ without ever defining a class; you cannot write even the simplest Java applet without extending the Applet class. You can write C++ without ever handling an exception, relying on the system's exception handler; you cannot successfully compile a Java program that could generate an exception unless you have handled the exception in your own code. If you write an applet with threads that sleep periodically, the run method will not even compile unless it contains a try/catch clause for the InterruptedException. I get several e-mails a day from beginning programmers asking me "What language should I learn?" I often wind up recommending easy visual programming environments like Visual Basic or Delphi. I sometimes recommend the student editions of C++ Builder or Visual C++, when I think the requester has enough background. I haven't yet recommended Java to a beginner because I haven't yet met a beginner who knows about objects and classes and exceptions. If I ever encounter such a beast, will he or she really be a beginner? Martin Heller programs and writes about programming from Andover, Mass. View Martin's Web site at http://www.winmag.com/people/mheller/. You can reach Martin via e-mail at mheller@winmag.com or care of the editor at the e-mail addresses here.
|