(3)chapter 5: The Java Virtual Machine II

The Class Loader Subsystem

     primordial class loader and class loader object

The primordial class loader is a class loader implemented in JVM, and class loader object is the objects of classes that descend from ClassLoader.

only types loaded by primordial class loader are stored in method area.

Loading, Linking and Initialization

1. loading: finding and importing the binary data for a type
2. linking: performing verification, preparation, and (optionally) resolution
    a. verification: ensuring the correctness of the imported type
    b. preparation: allocating memory for class variables and initializing the memory to default values
    c. resolution: transforming symbolic references from the type into direct reference.
3. initialization: invoking java code that initializes class variables to their proper starting values

Class Loader Object
   three methods in ClassLoader :
protected final Class defineClass(byte[] data, int offset, int length)
protected final Class findSystemClass(String name)
protected final void resolveClass(Class c)

The defineClass() method accepts a byte array, data[], as input. Starting at position offset in the array and continuing for length bytes, class ClassLoader expects binary data conforming to the Java class file format--binary data that represents a new type for the running application. Every Java Virtual Machine implementation must make sure the defineClass() method of class ClassLoader can cause a new type to be imported into the method area.

The findSystemClass() method accepts a String representing a fully qualified name of a type. When a class loader object invokes this method, it is requesting that the virtual machine attempt to load the named type via its primordial class loader. If the primordial class loader has already loaded or successfully loads the type, it returns a reference to the Class object representing the type. If it canít locate the binary data for the type, it throws ClassNotFoundException. Every Java Virtual Machine implementation must make sure the findSystemClass() method can invoke the primordial class loader in this way.

The resolveClass() method accepts a reference to a Class instance. This method causes the type represented by the Class instance to be linked and initialized (if it hasnít already been linked and initialized). The defineClass() method, described above, only takes care of loading. (See the above section, "Loading, Linking, and Initialization" for definitions of these terms.) When defineClass() returns a Class instance, the binary file for the type has definitely been located and imported into the method area, but not necessarily linked and initialized. Java Virtual Machine implementations make sure the resolveClass() method of class ClassLoader can cause the class loader subsystem to perform linking and initialization.

The Method Area
Type Information

For each type it loads, a Java Virtual Machine must store the following kinds of information in the method area:

   The fully qualified name of the type
   The fully qualified name of the typeís direct superclass (unless the type is an           interface or class java.lang.Object, neither of which have a superclass)
   Whether or not the type is a class or an interface
   The typeís modifiers ( some subset of` public, abstract, final)
    An ordered list of the fully qualified names of any direct superinterfaces

In addition to the basic type information listed above, the virtual machine must also store for each loaded type:

   The constant pool for the type
   Field information
   Method information
   All class (static) variables declared in the type, except constants
   A reference to class ClassLoader
   A reference to class Class