|
|
Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs
Page 3 of 6
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.
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 Volcano.
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 Volcano 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 download class Volcano, that Volcano class could then play a role in the application's future course of execution.
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 String 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 String class back to your class loader.
The primordial class loader most likely didn't have to actually load String at this point because, given that 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 returned the String class that it had previously loaded from the trusted repository.