System, but they may not be reproduced for publication

bytecode. This may come as a bit of a surprise because many modern languages are
designed to be compiled into CPU­specific, executable code due to performance
concerns. However, the fact that a Java program is executed by the JVM helps solve the
major problems associated with web­based programs. Here is why.
Translating a Java program into bytecode makes it much easier to run a program in a
wide variety of environments because only the JRE (which includes the JVM) needs to
be implemented for each platform. Once a JRE exists for a given system, any Java
program can run on it. Remember, although the details of the JRE will differ from
platform to platform, all JREs understand the same Java bytecode. If a Java program
were compiled to native code, then different versions of the same program would have
to exist for each type of CPU connected to the Internet. This is, of course, not a feasible
solution. Thus, the execution of bytecode by the JVM is the easiest way to create truly
portable programs.
The fact that a Java program is executed by the JVM also helps to make it secure.
Because the JVM is in control, it manages program execution. Thus, it is possible for
the JVM to create a restricted execution environment, called the sandbox, that contains
the program, preventing unrestricted access to the machine. Safety is also enhanced by
certain restrictions that exist in the Java language.
When a program is interpreted, it generally runs slower than the same program would
run if compiled to executable code. However, with Java, the differential between the
two is not so great. Because bytecode has been highly optimized, the use of bytecode
enables the JVM to execute programs much faster than you might expect.
Although Java was designed as an interpreted language, there is nothing about Java
that prevents on­the­fly compilation of bytecode into native code in order to boost
performance. For this reason, the HotSpot JVM was introduced not long after Java’s
initial release. HotSpot includes a just­in­time (JIT) compiler for bytecode. When a JIT
compiler is part of the JVM, selected portions of bytecode are compiled into executable
code in real time on a piece­by­piece demand basis. That is, a JIT compiler compiles
code as it is needed during execution. Furthermore, not all sequences of bytecode are
compiled—only those that will benefit from compilation. The remaining code is simply
interpreted. However, the just­in­time approach still yields a significant performance
boost. Even when dynamic compilation is applied to bytecode, the portability and safety
features still apply because the JVM is still in charge of the execution environment.
One other point: Beginning with JDK 9, some Java environments will also support an

---

ahead­of­time compiler that can be used to compile bytecode into native code prior to
execution by the JVM, rather than on­the­fly. Ahead­of­time compilation is a
specialized feature and it does not replace Java’s traditional approach just described.
Because of the highly sophisticated nature of ahead­of­time compilation, it is not
something that you will use when learning Java, and it is not discussed further in this
book.
Ask the Expert
Q
: I have heard about a special type of Java program called a servlet.
What is it?
A
: A Java servlet is a small program that executes on a server. Servlets
dynamically extend the functionality of a web server. It is helpful to understand
that as useful as client­side applications can be, they are just one half of the
client/server equation. Not long after the initial release of Java, it became obvious
that Java would also be useful on the server side. The result was the servlet. Thus,
with the advent of the servlet, Java spanned both sides of the client/server
connection. Although the topic of servlets, and server­side programming in
general, is beyond the scope of this beginner’s guide, they are something that you
will likely find of interest as you advance in Java programming.
Moving Beyond Applets
At the time of this writing, it has been more than two decades since Java’s original
release. Over those years, many changes have taken place. At the time of Java’s
creation, the Internet was a new and exciting innovation; web browsers were
undergoing rapid development and refinement; the modern form of the smartphone
had not yet been invented; and the near ubiquitous use of computers was still a few
years off. As you would expect, Java has also changed and so, too, has the way that Java
is used. Perhaps nothing illustrates the ongoing evolution of Java better than the
applet.
As explained previously, in the early years of Java, applets were a crucial part of Java
programming. They not only added excitement to a web page, they were a highly visible