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
Understanding the Java ClassLoader
Understanding Network Class Loaders
Internals of Java Class Loading