t gain access to each other unless the application explicitly allows it. When you write a Java application, you can segregate classes loaded from different sources into different name spaces. In this way, you can use Java's class loader architecture to control any interaction between code loaded from different sources. You can prevent hostile code from gaining access to and subverting friendly code.
Class loaders for
One example of dynamic extension with class loaders is the Web browser, which uses class loader objects to download the class files for an applet across a network. A Web browser fires off a Java application that installs a class loader object -- usually called an applet class loader -- that knows how to request class files from an HTTP server. Applets are an example of dynamic extension, because when the Java application starts, it doesn't know which class files the browser will ask it to download across the network. The class files to download are determined at run time, as the browser encounters pages that contain Java applets.
The Java application started by the Web browser usually creates a different applet class loader object for each location on the network from which it retrieves class files. As a result, class files from different sources are loaded by different class loader objects. This places them into different name-spaces inside the host Java application. Because the class files for applets from different sources are placed in separate name-spaces, the code of a malicious applet is restricted from interfering directly with class files downloaded from any other source.
Cooperation between class
Often, a class loader object relies on other class loaders -- at the very least, upon the primordial class loader -- to help it fulfill some of the class load requests that come its way. For example, imagine you write a Java application that installs a class loader whose particular manner of loading class files is achieved by downloading them across a network. Assume that during the course of running the Java application, a request is made of your class loader to load a class named
One way you could write the class loader is to have it first
ask the primordial class loader to find and load the class from
its trusted repository. In this case, since
is not a part of the Java API, assume the primordial class loader
can't find a class named
Volcano. When the
primordial class loader responds that it can't load the class,
your class loader could then attempt to load the
Volcano class in its custom manner, by downloading
it across the network. Assuming your class loader was able to
class could then play a role in the application's future course
To continue with the same example, assume that some time later
a method of class
Volcano is invoked for the first
time, and that the method references class
from the Java API. Because it is the first time the reference is
used by the running program, the virtual machine asks your class
loader (the one that loaded
Volcano) to load
String. As before, your class loader first passes
the request to the primordial class loader, but in this case, the
primordial class loader is able to return a
class back to your class loader.
The primordial class loader most likely didn't have to
String at this point because, given
String is such a fundamental class in Java
programs, it was almost certainly used before and therefore
already loaded. Most likely, the primordial class loader just
String class that it had previously
loaded from the trusted repository.
Since the primordial class loader was able to find the class,
your class loader doesn't attempt to download it across the
network; it merely passes to the virtual machine the
String class returned by the primordial class
loader. From that point forward, the virtual machine uses that
String class whenever class
references a class named
Class loaders in the
In Java's sandbox, the class loader architecture is the first line of defense against malicious code. It is the class loader, after all, that brings code into the JVM -- code that coul