Some would say that Java is the fastest-growing computer language that any of us have ever seen.  It continually attracts new programmers, and applications written in the language and for the Java environment are being introduced at a faster pace.

On one level, Java is a programming language. But just as Windows is more than just a graphical user interface, Java is more than just another way to write code. Still, it makes sense to start there.

The Java language is superficially similar to the wildly popular C++, so C++ programmers generally find it easy to learn Java's syntax. And as our story "Java Development Packages" reveals, Java development packages mirror the RAD approach popularized with C++. But unlike C++, Java is object-oriented from the ground up. This helps programmers enforce good object-oriented practices, which leads to more maintainable code.

As with C++ and C, much of what is usually lumped together as Java - "the programming language" - consists of runtime libraries. These libraries provide a standard set of facilities for manipulating the user interface, communicating across a network, and so forth. Consistency in the runtime libraries is important for achieving the "write once, run anywhere" claim and is in fact the focus of one Sun lawsuit against Microsoft. (The lawsuit alleges that Microsoft fails to provide two Java runtime libraries--RMI, forremote method invocation, and JNI, for Java native interface--and that Microsoft has engineered subtle but impermissible changes into the behavior of core Java libraries.)

Indeed, in late 1996, Sun launched its 100% Pure Java initiative, which examines each "Java product" against a tightly guarded certification process. Products that pass are labeled as 100% Pure Java and carry the guarantee that they use only standard Java features and should, theoretically, run on any properly implemented version of Java.

Sun currently lists more than 120 such products at its 100% Pure Web site. But there's one hitch: No widely used Java VM meets Sun's compatibility requirements. Netscape pulled the Java logo from its browser in late 1997, because its implementation was not fully compliant; Sun and Microsoft remain embroiled in legal battles over Microsoft Internet Explorer.

And yet, Java is more than just a programming language. If Java were just another programming language, the industry would have greeted its introduction with a resounding yawn. What makes Java intriguing is that it is also a runtime environment embodied in what is called a virtual machine (VM).

This VM sits, in essence, between the Java program and the machine it is running on, offering the program an "abstract computer" that executes the Java code and guarantees certain behaviors regardless of the underlying hardware or software platform. Java compilers thus turn Java programs not into assembly language for a particular machine but into a platform-neutral "byte code" that the machine-specific VM interprets on the fly.

The Java VM also enforces security policies, providing a sandbox that limits what the Java program can do. A Java applet cannot, for example, peek into arbitrary files on the machine it's running on. The most recent version of Java from Sun, known as Java Development Kit (JDK) 1.1, though, provides no consistent method for an applet to request restricted system resources. This capability will be available in JDK 1.2, due out later this year.

The lack of a consistent mechanism for accessing local files is one major impediment to Java's success as a replacement for traditional productivity applications on the desktop.

The Java VM is not the industry's first attempt to develop a platform-independent computing environment. But Java has gained widespread attention where other attempts have failed, in large part because the VM was distributed with browsers beginning with Navigator 2.0, thus giving Java unprecedented initial market penetration.

As our story "Java Environments" shows, however, the VMs on different platforms today simply don't behave similarly. This makes debugging a serious problem for Java deployment in a heterogeneous environment.

The compatibility situation is likely to get worse before it gets better: JDK 1.1 is a substantial change from JDK 1.0, which means that compatibility between the two is not assured. And the delivery of JDK 1.1 support in VMs has been surprisingly slow: JDK 1.1 is only partly implemented in Netscape Communicator and is largely implemented in Internet Explorer 4.0.

Moreover, even if all the VMs operated properly, "write once, run anywhere" is not necessarily a panacea. In fact, it places significant hurdles in the path of developers. For one thing, the Java VM generally presents applications using a given machine's native user-interfacewidgets (components such as command buttons and drop-down boxes). Thus, Java programs act in a fashion familiar to users on a given platform. But this also destroys user-interface consistency from platform to platform, which makes testing a serious problem. (The forthcoming JDK 1.2 contains support for "pluggable" user interfaces intended to alleviate this problem.)

In addition, "write once, run anywhere" implies a lowest common-denominator approach. To offer one often-cited example, not all computers (specifically Macs) offer a right mouse button. Should programmers have to forgo offering context-sensitive pop-up menus for every platform as a result?

Compared with native code, Java VMs are excruciatingly slow. The advent of just-in-time (JIT) compilers in Version 3.0 browsers, at least on the PC platform, helped alleviate this shortcoming. But for many applications, Java still cannot compete with natively compiled C++ code.

A key addition to JDK 1.1 is support for JavaBeans, a component model for Java. JavaBeans make it easy to write reusable components that can be strung together with a minimum of additional coding. Although Microsoft's ActiveX offers similar advantages, Beans are less focused on a Windows-centric world and are somewhat more portable. Still, ActiveX does have the advantage of supporting any underlying programming language, while Beans are designed solely to encapsulate Java.

Java and the Java VM together provide a set of services that Java programs can rely on, regardless of the underlying hardware and OS. In this respect, Java has become positioned as a new platform--a target environment for applications.