In order to achieve this level of portability, Java must be very precise not only about the language itself, but about the environment in which the language lives.
You can see, that the Java environment includes a generally useful set of packages of classes and a freely available implementation of them. This takes care of a part of what is needed, but it is crucial also to specify exactly how the run-time environment of Java behaves.
This final requirement is what has stymied many attempts at ubiquity in the past. If you base your system on any assumptions about what is "beneath" the run-time system, you lose. If you depend in any way on the computer or operating system below, you lose. Java solves this problem by inventing an abstract computer of its own and running on that.
This "virtual" machine runs a special set of "instructions" called bytecodes that are simply a stream of formatted bytes, each of which has a precise specification of exactly what each bytecode does to this virtual machine. The virtual machine is also responsible for certain fundamental capabilities of Java, such as object creation and garbage collection.
Finally, in order to be able to move bytecodes safely across the Internet, you need a bulletproof model of security—and how to maintain it—and a precise format for how this stream of bytecodes can be sent from one virtual machine to another.
It is worth quoting the introduction to the Java virtual machine documentation here, because it is so relevant to the vision outlined earlier:
The Java virtual machine specification has a purpose that is both like and unlike equivalent documents for other languages and abstract machines. It is intended to present an abstract, logical machine design free from the distraction of inconsequential details of any implementation.
It does not anticipate an implementation technology, or an implementation host. At the same time it gives a reader sufficient information to allow implementation of the abstract design in a range of technologies.
However, the intent of the … Java project is to create a language … that will allow the interchange over the Internet of "executable content," which will be embodied by compiled Java code. The project specifically does not want Java to be a proprietary language, and does not want to be the sole purveyor of Java language implementations.
Rather, we hope to make documents like this one, and source code for our implementation, freely available for people to use as they choose.
This vision … can be achieved only if the executable content can be reliably shared between different Java implementations. These intentions prohibit the definition of the Java virtual machine from being fully abstract. Rather, relevant logical elements of the design have to be made sufficiently concrete to allow the interchange of compiled Java code.
This does not collapse the Java virtual machine specification to a description of a Java implementation; elements of the design that do not play a part in the interchange of executable content remain abstract. But it does force us to specify, in addition to the abstract machine design, a concrete interchange format for compiled Java code.
The Java virtual machine (JVM) specification consists of the following:
- The bytecode syntax, including opcode and operand sizes, values, and types, and their alignment and endian-ness
- The values of any identifiers (for example, type identifiers) in bytecodes or in supporting structures
- The layout of the supporting structures that appear in compiled Java code (for example, the constant pool)
- The Java .class file format
Each of these is covered in this chapter.
Despite this degree of specificity, there are still several elements of the design that remain (purposely) abstract, including the following:
- The layout and management of the run-time data areas
- The particular garbage-collection algorithms, strategies, and constraints used
- The compiler, development environment, and run-time extensions (apart from the need to generate and read valid Java bytecodes)
- Any optimizations performed, once valid bytecodes are received
These places are where the creativity of a virtual machine implementor has full rein.
Latest JVMs available at oxxus.net java hosting provider.
The Fundamental Parts
The Java virtual machine can be divided into five fundamental pieces:
- A bytecode instruction set
- A set of registers
- A stack
- A garbage-collected heap
- An area for storing methods
Some of these might be implemented by using an interpreter, a native binary code compiler, or even a hardware chip—but all these logical, abstract components of the virtual machine must be supplied in some form in every Java system.
The virtual machine, and its supporting code, is often referred to as the run-time environment.