An introduction to java class loader

 

An introduction to java class loader

A
ClassLoader's basic purpose is to service a request for a class. The
JVM needs a class, so it asks the ClassLoader, by name, for this
class, and the ClassLoader attempts to return a Class object that
represents the class. By overriding different methods corresponding
to different stages of this process, you can create a custom
ClassLoader.

The
following is a high-level class-loading algorithm executed by a
ClassLoader when a client requests it to load a class:

• A
  check is performed to see if the requested class has already been
  loaded by the current ClassLoader. If so, the loaded class is
  returned and the request is completed. The JVM caches all the
  classes that are loaded by a ClassLoader. A class that has
  previously been loaded by a ClassLoader is not loaded
  again.(ClassLoader#findLoadedClass())

• If
  the class is not already loaded, the request is delegated to the
  parent ClassLoader, before the current ClassLoader tries to load it.
  This delegation can go all the way up to the bootstrap ClassLoader,
  after which no further delegation is possible.
  (ClassLoader#findSystemClass())

• If
  a parent fails to return a class because it was unable to load it,
  the current ClassLoader will then try to search for the requested
  class. Each ClassLoader has defined locations where it searches for
  classes to load. For instance, the bootstrap ClassLoader searches in
  the locations (directories and zip/jar files) specified in the
  
  sun.boot.class.path
  
  
  system property. The system ClassLoader searches for classes in the
  locations specified by the classpath (set as the
  java.class.path
  
  
  system property) command-line variable passed in when a JVM starts
  executing. If the class is found, it's loaded into the system and
  returned, completing the request.

• If
  the class is not found, a java.lang.ClassNotFoundException is
  thrown.

In
java 1.1, there were no relations between system class loader
(responsible
for loading
in the Java runtime, the application, and classes and resources in
the application's CLASSPATH) and applet class loader (loaded classes
over networks).

Since
Java 1.2 we have three types of class loaders:

• Class
  loaders created automatically by the JVM

• Program
  defined class loaders

• Context
  class loaders.

There are three Class loaders in
first group:

• bootstrap
  class loader - loads classes from ../jre/lib/rt.jar It is the "root"
  in the class loader hierarchy.

• extensions
  class loader - loads classes from ../jre/lib/ext/*.jar

• system
  class loader - it is responsible for loading in the application, as
  well as for loading classes and resources in the application's
  CLASSPATH.

Second group includes:

• system
  class loader - parent class loader by default

• additional
  parent class loader can be specified explicitly

Third group is context class
loader. A thread's context class loader is, by default, set to the
context class loader of the thread's parent. The hierarchy of threads
is rooted at the primordial thread (the one that runs the program).
The context class loader of the primordial thread is set to the class
loader that loaded the application. So unless you explicitly change
the thread's context class loader, its context class loader will be
the application's class loader. That is, the context class loader can
load the classes that the application can load.
T
o
change a thread's context class loader, use
Thread.setContextClassLoader().

For more information:

The
basics of Java class loaders

Security
and the class loader architecture

The
Class Loader Architecture

Understanding
the Java ClassLoader

Understanding
Network Class Loaders

Internals
of Java Class Loading

java.lang.ClassLoader