HomeDigital EditionSys-Con RadioSearch Java Cd
Advanced Java AWT Book Reviews/Excerpts Client Server Corba Editorials Embedded Java Enterprise Java IDE's Industry Watch Integration Interviews Java Applet Java & Databases Java & Web Services Java Fundamentals Java Native Interface Java Servlets Java Beans J2ME Libraries .NET Object Orientation Observations/IMHO Product Reviews Scalability & Performance Security Server Side Source Code Straight Talking Swing Threads Using Java with others Wireless XML

The key selling feature of Java is its WORA (write once, run anywhere) promise. Let's pause and think about what's involved in making this promise a reality. "Write Once" is a concept that applies specifically to the Java language, the idea being that there is one and only one standard definition of the programming language that developers use for writing application code. In terms of syntax and semantics, this means the definition of the language is fixed, and any changes are routed through Sun Microsystems, the official owners of the Java Platform.

Providing a standard definition for Java's syntax and semantics is a feasible proposition. The "Run Anywhere" part of WORA is a much harder goal to achieve. "Anywhere" refers to the combination of hardware platforms and operating systems on which software written in the language can run. This mandates platform neutrality. All code written in a software programming language is compiled down to machine (assembler) code that is specific to a particular hardware platform; that is, the resultant machine instructions run on a particular CPU. Thus, to have the code run anywhere, the same source should compile to different machine instructions.

The Compilation Process
One way of translating programming language source code into native platform code is to provide the compiler with flags or directives that cause it to compile to a specific instruction set. However, this necessitates that the programmer or installer of the code provide the directives, depending on the hardware environment. Customizing source code from a high-level language for multiple platforms is not an easy task. Also, the precompiler directives have to be embedded in the source code, which adds to the code's complexity. At some point the precompiler directives may actually be viewed as a part of the language itself. The result is that several incarnations of the language coexist and platform neutrality becomes impossible. Porting the code becomes a nightmare.

The other approach involves breaking down the process of compilation in two stages. First, an abstract "platform" that the programming language compiles to is defined. This is not an actual platform, but rather an instruction set definition for a "virtual machine" (VM). The code written in the programming language always compiles to this VM, regardless of the actual hardware platform. The next stage of this approach is to translate the machine instructions of the VM to native hardware-specific assembler code. Figure 1 illustrates these two approaches for source code compilation.

Figure 1
Figure 1:

This probably sounds like six of one and half a dozen of the other. And it is. The end result is the same - programming language code is translated (compiled) down to native machine code. The difference, however, is that the responsibility of configuring the compilation process is abstracted away from the programmer. Programmers write source code that always compiles to the same virtual machine. The virtual machine code is interpreted by a runtime VM that translates each virtual instruction into native code. The programming cycle becomes less complex, source code written and compiled on any platform runs on any other and the world is a happy place.

The Java Virtual Machine
The Java Virtual Machine (JVM) is an abstract machine that provides a specification for running compiled Java code. The specification allows flexibility in implementing the features of the VM. All JVM implementations need to support the execution of Java bytecodes, which are the virtual machine instructions that Java source code compiles to. However, the specification does not dictate how the bytecodes have to be executed. This functionality is provided by the vendor who provides the runtime environment. The VM may be implemented completely in software or, to varying degrees, in hardware. This flexibility allows the JVM to be implemented on a variety of computers and hardware devices.

The Java programming environment thus may be categorized into two computing environments. The compile-time environment provides the translation of Java source code to bytecodes (.class files). The runtime environment provides the interpretation of the bytecodes into native platform code. Figure 2 illustrates the role of the JVM.

Figure 2
Figure 2:

The specifications of the JVM are officially released by Sun Microsystems. This means that the definition of the virtual machine instruction set is standardized by a single source. The specifications of the Java APIs are also officially released by Sun Microsystems. The JVM and the Java APIs constitute the Java Platform, or the Java runtime system.

As far as Java Virtual Machines go, we're not just in Cupertino anymore. While it's true that the official Java language definition is still provided by Sun Microsystems, alternate definitions of the JVM are creeping into the computing arena. Of these, the ones that have attracted the most attention are the Microsoft Virtual Machine for Java and the HP-Embedded Virtual Machine for Java. Both diverge from Sun's specifications for a Java Virtual Machine. Another JVM of interest for our discussion here is the long-awaited Sun Microsystems' HotSpot JVM.

This month the Cosmic Cup briefly examines the three JVMs mentioned above. While the first two "stray" from the specification, HotSpot adheres to it (after all, it is being developed by Sun), and illustrates a novel implementation of the JVM specification. These JVMs are shown in Table 1. They are discussed in the next section.

Table 1

HotSpot Java Virtual Machine
The HotSpot JVM, an implementation of the standard Java Virtual Machine, is expected to provide significantly higher performance than other JVM implementations. It uses a variety of techniques to gain performance, including on-the-fly adaptive optimization technology, fast thread synchronization, a highly efficient garbage collector and an optimizing native code compiler. The key feature that makes HotSpot a novel implementation of the JVM specification is its use of modern dynamic compilation techniques to generate highly optimized code on the fly for specific execution environments. At the heart of the HotSpot JVM is the Java HotSpot Compiler. Unlike other compilers that compile the entire program before execution, the Java HotSpot VM runs the program immediately, using an interpreter, and analyzes it as it runs to detect the critical "hot spots" in the program.

The initial version of the Java HotSpot virtual machine has been designed to the JDK release version 1.2 specification, and is expected to be released at the same time as JDK 1.2.

Microsoft VM for Java
The Microsoft VM for Java provides a complete implementation of Sun's JVM specification. However, it provides extensions to the specifications that target Windows platforms. The VM extends the standard JVM to provide the capability to load component object model (COM) classes and expose COM interfaces of Java classes. This means that the Microsoft VM allows Java classes to exist as both standard Java classes and ActiveX controls. The Microsoft VM itself is implemented as an ActiveX control.

This extension of the standard VM negates Java's platform independence. Once applications are developed using the extensions, they become specific to Windows platforms and won't run in other environments. Microsoft's VM is provided with Internet Explorer, Java SDK and Visual J++, Microsoft's IDE for Java.

In addition to the extensions to the VM, the Visual J++ environment also provides an extension feature to the Java programming language - a new keyword, delegates, and a supporting keyword, multicast. Since our discussion here is focused on JVMs, I won't go into a discussion on the construct itself. What it signifies in our context is that this small addition to the language means that the code using these keywords will also be compiled down to the JVM implementation. In other words, Microsoft VM will have to provide the code for compiling the keywords in addition to the standard Java language construct.

HP-Embedded Virtual Machine for Java
The Hewlett-Packard-Embedded Virtual Machine for Java includes a core set of Java API implementations for java.lang, java.net, java.util and java.io APIs. It specifically targets the embedded device market. It is portable to MIPS-4300, Motorola 68 K, Intel 80x86 and sARM processor-based devices.

This VM is not an implementation of a JVM specification provided by Sun Microsystems, but an implementation of a completely different VM specification defined by Hewlett-Packard. The specification for HP's VM was announced prior to Sun's Embedded Java specification (which is its counterpart). HP's Embedded Virtual Machine for Java provides incremental garbage collection and optional Java class libraries (i.e., all the libraries need not be linked at runtime), and has a very small footprint (approximately 0.5 KB). It is supported on HP-UX/PA-RISC and Windows NT/Intel development platforms.

The HP-Embedded Virtual Machine for Java is currently available as release 1.0.

Cosmic Reflections
In an ideal Java universe the definition of the computing environment would come from one source, all businesses would agree to specifications and standards proposed by one representative vendor, software releases for the JDKs would be on time and robust and there would be only one development and deployment platform. None of these fantasies come true in the real world, however. Different aspects of the computing environment are addressed by different vendors. Optimizing performance requires platform dependence by its very definition. And no one source can satisfy the needs of the entire industry. Since the problems that Java is targeting address the entire business community, it's unrealistic to expect the Java Platform to be generic and at the same time address every facet of the industry. As Java matures, we should expect to see other independent implementations of its VM.

About the Author
Ajit Sagar is on the technical staff at i2 Technologies, Dallas, Texas, and a Java-certified programmer with eight years of programming experience. He holds a BS in electrical engineering from BITS Pilani, India, and an MS in computer science from Mississippi State. He can be reached at [email protected]


All Rights Reserved
Copyright ©  2004 SYS-CON Media, Inc.
  E-mail: [email protected]

Java and Java-based marks are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and other countries. SYS-CON Publications, Inc. is independent of Sun Microsystems, Inc.