java之Class Loading Architecture --《Java_Security_2nd_Edition》

      We'll show some examples of how to create and use class loaders a bit later in this chapter. First, let's examine

from a logical perspective how class loaders work.

     Class loaders are organized into a tree hierarchy. At the root of this tree is the system class loader. This class
loader is also called the primordial class loader or the null class loader. It is used only to load classes from the

core Java API.

  The system class loader has one or more children. It has at least one child; the URL class loader that is used to
load classes from the classpath. It may have other direct children, though typically any other class loaders are
children of the URL class loader that reads the classpath. An example class loader hierarchy is shown in
Figure 6−2; this is the hierarchy that might exist within the Java Plug−in after it has loaded applets from both

www.sun.com and www.ora.com.

                         Figure 6−2. A class loader hierarchy

     

    The hierarchy comes into play when it is time to load a class. Classes are loaded in one of three ways: either
explicitly by calling the loadClass( ) method of a class loader, explicitly by calling the
Class.forName( ) method, or implicitly when they are referenced by an already−loaded class.

   In any case, a class loader is asked to load the class. In the first case, the class loader is the object on which
the loadClass( ) method is invoked. In the case of the forName( ) method, the class loader is either
passed to that method, or it is the class loader that loaded the class that is calling the forName( ) method.
The implicit case is similar: the class loader that was used to load the referencing class is also used to load the

referenced class.

   Class loaders are responsible for asking their parent to load a class; only if that operation fails will the class
loader attempt to define the class itself. Take the case of the class com.sun.Car that was loaded by the
URL class loader that knows about www.sun.com. When that Car class references the
java.lang.String class, the same URL class loader will be asked to provide the String class object. It
will ask its parent (the URL class loader for the classpath) to provide that class. Its parent will in turn ask the
system class loader to provide that class. Since the system class loader knows about the
java.lang.String class, it will return the appropriate class.

   Note, however, that if the com.sun.Car class references the com.ora.Ferrari class, class loading will
fail: the class loader that is associated with www.ora.com is not in the ancestor path of the class loader that is
associated with www.sun.com.

  The net effect of this is that system classes will always be loaded from the system class loader, classes on the
class path will always be loaded by the class loader that knows about the classpath, and in general, a class will
be loaded by the oldest class loader in the ancestor hierarchy that knows where to find a class.

  When you create a class loader, you can insert it anywhere into the hierarchy of class loaders (except at the
root). Typically, when a class loader is created, its parent is the class loader of the class that is instantiating the
new class loader.