Your Guide to Java

Not Just a 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.

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. (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.

Continued...

PREVIOUS

NEXT