![]() |
|||
![]() ![]() |
![]() |
|
![]() |
Relating the Java Runtime Environment and the Java Virtual MachineIt sounds odd to say, This executable runs on any machine with an Intel architecture. A more common statement is to say, This executable runs on any Windows 95 platform. The difference is that the first sentence describes the machine architecture, such as Intel, Motorola, or Sun. The second makes a more specific statement about the operating system in which the executable may be run. Likewise, the JVM provides Java executables with a machine architecture to be executed on, and the runtime provides basic operating system functionality. When there was only one version of the Java runtime environment, you could assume that any machine with a JVM would execute a Java class file. With the release of JDK 1.1, saying that a machine is Java-enabled is not enough. Current Java applications written with JDK 1.1 will not run on a JDK 1.02-compatible runtime, but they will run on a JDK 1.02-compliant JVM. The difference lies in the support files provided by the runtime environment. Put simply, the JVM emulates a Java Chip. It knows only how to execute the Java machine instruction set. The support classes required by Java executables, like the java.lang package, reside in the runtime environment and are fetched by the JVM as needed. In this manner, the JVM can remain common between JDK versions with only the support classes changing. Figure 1.2 illustrates how the JVM uses the files found in the runtime environment to execute a class file.
As you can see from Figure 1.2, the Java runtime environment acts as an operating system of sorts, loading required classes into the JVM for execution. In this way, the Java runtime environment acts as the interface between the native machine and the JVM. Later in this chapter, a section entitled Executing A Class in the JVM diagrams the complete execution of a class file to demonstrate exactly how the runtime and JVM interact. But for now, think of the JVM as a piece of the Java runtime environment, and remember that the JVM requires the facilities of the runtime to execute Java classes. Old Technology Revisited About 1977, a project by the name p-system was being developed at the University of California San Diego under Professor Kenneth Bowles . The goal of the p-system project was to create a ubiquitous operating system providing a common platform for application executions through the use of a virtual machine architecture. Keep in mind this was several years before the first IBM PC, Macintosh, or Amiga hit the market. Computer architectures at the time were vastly different, and the concept of providing a solution to machine-specific, or native applications was revolutionary. The p-system was and is an enormous success. By 1985, p-systems were running on the DEC LSI-11, the Zilog Z80, the Motorola 68000, and almost every member of the Intel 80*86 family from the 8088 to the 80386. Even today, Cabot Software of the United Kingdom continues to sell newer versions under license as a alternative for Java. At the time the first JDK was released for public use, virtual machine technology was almost 20 years old. Without a doubt, the p-system played a major role in designing, sculpting, and stabilizing the JVM. Cross-Platform Capabilities The JVM was designed to provide Java executables with a standard platform for execution. However, if the JVM was only implemented on a single platform, Java technology would not offer anything more than native-compiled applications. Javas intrinsic benefits, and its ultimate ubiquity, come from the number of different platforms which provide a Java runtime environment. Today, the JVM and Java runtime environment are available on an increasing number of platforms. The following is a partial list of supported platforms:
JVM ArchitectureThe JVM is probably one of the most misunderstood technologies of the Java suite. Some say that the JVM is an interpreter, interpreting Java-compiled byte code into actual native machine calls. This statement isnt entirely false, but it is not true enough to be right. That is, the JVM is a virtual machine; it is not an interpreter, but rather an emulator. Virtual machine technology has historically been distinct from interpreter technology. The reason lies in how and at what level the interpretation takes place. Interpreters directly map a proprietary byte code into system calls. Some map directly into machine instructions, but no attempt is made, by any interpreter, to emulate an intermediate machine architecture. The JVM functions like an interpreter in some areas, but this comparison is not a direct one. If anything, you can generally refer to interpreters as scaled-down, simplified, and altogether less-complicated forms of a virtual machine. As you will see in the next few sections, the JVM is an entire framework for a machine architecture, not unlike Intel or Motorola. The only difference is that the JVM does not require a chip- or silicon-based implementation to operate. JVM ExaminedIf you have never gone through the agony of writing programs directly to a machines hardware, the similarities between existing silicon-based architectures and the JVM are probably not obvious to you. Nevertheless, it is important to realize the level at which the JVM executes class files. The JVM is an entire machine architecture with the capability of being implemented directly into a silicon chip. The JVMs architecture revolves around the concept of an implementation that is not machine-specific. That is, the architecture itself makes no assumptions about the machine or silicon on which it is implemented. In this way, the JVM is the sole and autonomous entity that executes class files. As shown in Figure 1.3, the JVM is broken into five distinct units of functionality, which all work in harmony to achieve the primary task of executing class files.
The following sections analyze the functionality of each of the five key JVM units. Throughout this discussion, keep in mind how closely the JVM maps to existing and potential silicon-based architectures. These units are:
|
![]() |
|