Java Reference
In-Depth Information
In an Internet environment, the movement to the execution machine (an end
user's PC, for example) is automatically performed by the browser without any spe-
cial commands by the user. The net result is simplified administration of the appli-
cations and immediate access to any Java application for the end user.
To accomplish this, the Java compiler does not create
executable
code—meaning
a program that runs natively on a given system. Instead, the Java compiler creates an
intermediate representation
of your program. This representation is somewhere
between source code and native machine code. It is called
Java byte codes
. These byte
codes are the content that is moved to a computer system at runtime to be executed
on that system.
Since the byte codes are not in a format that is native to any system, they can't
be executed directly on any system. Instead, a native program interprets the byte
codes and performs the application functions expressed in the byte codes. This in-
terpreter is called a
Java virtual machine
, because it creates a virtual system envi-
ronment in which Java byte codes can execute.
This concept is not new. Interpreted languages such as LISP and SmallTalk
have worked this way for years. Some cross-platform COBOL compilers (notably
from MicroFocus and AcuCorp) also provide this same type of “instantaneous
portability” feature, using a byte code or intermediate version of compiled COBOL
programs. Also, Ruby on Rails, ASP.NET (where multiple languages can be used for
the output of byte codes), PHP, PERL, Python, and so on provide some form of vir-
tual machine environment. Figure 2.1 shows the compile and execution procedure
for a simple Java application.
In theory, the only prerequisite for running a Java program on a system is that
an appropriate Java virtual machine be available on that system. As you might sus-
pect, the reality is somewhat different.
Operating system functions and some details of the way an application inter-
acts with the operating system are not exactly the same across all operating systems.
Java does a credible job of defining standards that shield most applications from
these differences, but it does not cover
all
cases. As a result, some low-level appli-
cation functions are not defined by Java, or they are left to the individual VM im-
plementation to deliver.
A good example of these issues is the curious fact that Java doesn't define a
universal (or “pure Java”) notion of a standard output display device. The
System.out.println
statement in Figure 2.1 is not technically 100% pure Java,
even though it appears in almost every Java reference manual! It is left up to the Java
VM's implementation of the
System.out
object to decide what to do with
System.out.println
.
