Home : Course Map : Chapter 4 : Java : Supplements :
Class Loaders
Course Map
Chapter 4

  Demo 1
  Demo 2a
  Demo 2b
  Demo 3
  Demo 4
Casting References
Object class
Class Summary

Java Security
Class Loading
Class Verifier
     About JavaTech
     Codes List
     Topic Index
     Course Guide
     What's New

To run a java an application, the JVM needs to load the class file with the main() method and the various supporting classes such as the Object class inherited by all Java classes. How does the JVM find a class file and turn its bytes into fields, methods, constructors, and so forth?

Most of the work of finding and building a class is done internally by the JVM but the visible part is provided by a class loader, which is an instance of a subclass of the abstract java.util.ClassLoader class (ref.1). A class loader provides the method

  Class c = loadClass(String className, boolean resolve);

to load an instance of Class with the name className. Here the argument resolve indicates whether classes referenced by the class should also be loaded.

As discussion the Class class section, the Class instance provides a description of the particular class that the JVM uses to create concrete instances of it.

Though part of a JVM is written in C, much of the core capabilities come from base classes written in Java. The JVM needs to load these classes to build itself. The JVM uses a bootstrap (also called primordial) class loader to install the core classes.

This loader obtains files from the local disks. It also will load the user classes in files found in the local disks via the CLASSPATH setting.

(Actually, as of Java 1.2, there are three default classloaders in a hierarchy beginning with the bootstrap classloader to load core classes, and then an extension classloader for the available extension classes, and the system classloader for classes on the CLASSPATH. See ref. 2 and ref. 3 for details.)

However, obtaining classes from other sources, such as the Internet, requires separate classloaders. Custom class loaders can be created by subclassing the abstract ClassLoader class ( ref. 3). This can be particularly useful for cases where classes must be loaded in ways other than reading from a local directory. For example, browser JVMs use an AppletClassLoader object to load classes via HTTP (Hypertext Transport Protocol.) Different applets loaded at the same time may be assigned new classloader objects for each.

Note that these supplemental classloaders provide additional security capabilities. The applet class loader, for example, does extra checking on the downloaded class file to reject any pathological code. Also, namespaces can be kept distinct. For example, there is nothing to prevent you from creating a java.lang package in your applet codebase. It might seem that a hacker could thus replace core language classes with diabolical classes. However, since two different classloaders represent the classes, the JVM has no trouble in keeping the classes separate and avoiding the use of fake core classes.

Class Loading Procedure

The procedure followed to obtain and install a class goes as follows (ref.1):

  1. Loading includes the following tasks:
    • locate the bytecode file in a disk file, JAR, URL address, etc.
    • read it into the JVM's method area on the heap.
    • parse the class data into sections for constants, methods, fields, etc..
    • create an instance of java.lang.Class to represent the class.

  2. Linking proceeds through these 3 steps
    1. verification - check that the basic structure and form of the class is proper. Run bytecode verification.
    2. preparation - allocate memory for the class data such as static variables.
    3. resolution - convert the symbolic references in the class file, such as variable names, to direct references.

  3. Initialization
    The static variables and constants must be set to either default or user assigned values. The initialization code is collected into a special method called <clinit> that is invoke by the JVM.

Particular JVM implementations may vary the order of these steps somewhat. For example, a class might be loaded and cached to speed the processing before it is actually needed. Bytecode verification can be done all at once after the class is first read in or it could be done "on the fly" on individual instructions as they execute.

The loading talents of the classloaders is available also for loading other resources such as images, audio files, and so forth. See the Class class discussion.

We look more into bytecode verification in the next section.

References & Web Resources

Most recent update: Oct. 5, 2005

Vectors & Matrices

Runge-Kutta 2nd
  Demo 1
Runge-Kutta 4th
  Demo 2
Shooting Method
  Demo 3

  Part I Part II Part III
Java Core 1  2  3  4  5  6  7  8  9  10  11  12 13 14 15 16 17
18 19 20
22 23 24

1  2  3  4  5  6  7  8  9  10  11  12

Tech 1  2  3  4  5  6  7  8  9  10  11  12
Physics 1  2  3  4  5  6  7  8  9  10  11  12

Java is a trademark of Sun Microsystems, Inc.