How Java Class Loaders works .

he Java Class Loader is a part of the Java Runtime Environment that dynamically loads Java classes into the Java Virtual Machine. Usually classes are only loaded on demand. The Java run time system does not need to know about files and file systems because of classloaders. Delegation is an important concept to understand when learning about classloaders.
software library is a collection of related object code. In the Java language, libraries are typically packaged in JAR files. Libraries can contain objects of different types. The most important type of object contained in a Jar file is a Java class. A class can be thought of as a named unit of code. The class loader is responsible for locating libraries, reading their contents, and loading the classes contained within the libraries. This loading is typically done "on demand", in that it does not occur until the class is called by the program. A class with a given name can only be loaded once by a given classloader.
Each Java class must be loaded by a class loader.Furthermore, Java programs may make use of external libraries (that is, libraries written and provided by someone other than the author of the program) or they may be composed, at least in part, of a number of libraries.
When the JVM is started, three class loaders are used:

1.   Bootstrap class loader
2.   Extensions class loader
3.   System class loader
The bootstrap class loader loads the core Java libraries located in the /jre/lib directory. This class loader, which is part of the core JVM, is written in native code.
The extensions class loader loads the code in the extensions directories (/jre/lib/ext, or any other directory specified by the java.ext.dirs system property). It is implemented by the sun.misc.Launcher$ExtClassLoader class.
The system class loader loads code found on java.class.path, which maps to the CLASSPATH environment variable. This is implemented by the sun.misc.Launcher$AppClassLoader class.

JEE  Class Loaders

Java Platform, Enterprise Edition (Java EE) application servers typically load classes from a deployed WAR or EAR archive by a tree of classloaders, isolating the application from other applications, but sharing classes between deployed modules. So-called "servlet containers" are typically implemented in terms of multiple classloaders.

Recommendations for Multithreaded Custom Class Loaders
Custom class loaders that do not have a history of deadlocks do not require any changes. In particular, you do not need to change custom class loaders that follow the recommended acyclic hierarchical delegation model, that is, delegating first to their parent class. For backward compatibility, the Java SE 7 release continues to lock a class loader object unless it registers as parallel capable.
To create new custom class loaders, the process is similar in the Java SE 7 release as in previous releases. Create a subclass of ClassLoader, then override the findClass() method and possibly loadClass(). Overriding loadClass() makes your life more difficult, but it is the only way to use a different delegation model.
If you have a custom class loader with a risk of deadlocking, with the Java SE 7 release, you can avoid deadlocks by following these rules:
1.  Ensure that your custom class loader is multithread safe for concurrent class loading.

a. Decide upon an internal locking scheme. For example, java.lang.ClassLoader uses a locking scheme based on the requested class name.

b.    Remove all synchronization on the class loader object lock alone.

c.  Ensure that critical sections are safe for multiple threads loading different classes.

2.    In your custom class loader's static initializer, invoke java.lang.ClassLoader's static method registerAsParallelCapable(). This registration indicates that all instances of your custom class loader are multithread safe.
3.    Check that all class loader classes that this custom class loader extends also invoke the registerAsParallelCapable() method in their class initializers. Ensure that they are multithread safe for concurrent class loading.
If your custom class loader overrides only findClass(String), you do not need further changes. This is the recommended mechanism to create a custom class loader.
If your custom class loader overrides either the protected loadClass(String, boolean) method or the public loadClass(String) method, you must also ensure that the protected defineClass() method is called only once for each class loader and class name pair.

If your product ships and appears to have problems due to incomplete handling of critical sections, you can use a new VM flag -XX:+AlwaysLockClassLoader. This flag reverts to locking the class loader lock before invoking your custom class loader's findClass() or loadC

Class   Loader Class
5.1. The loadClass() Method
public Class loadClass(String name, boolean resolve) throws
 ClassNotFoundException {}
This method is responsible for loading the class given a name parameter. The name parameter refers to the fully qualified class name.
The Java Virtual Machine invokes loadClass() method to resolve class references setting resolve to true. However, it isn’t always necessary to resolve a class. If we only need to determine if the class exists or not, then resolve parameter is set to false.
This method serves as an entry point for the class loader.
We can try to understand the internal working of the loadClass() method from the source code of java.lang.ClassLoader:

protected Class loadClass(String name, boolean resolve)
  throws ClassNotFoundException {

    synchronized (getClassLoadingLock(name)) {
        // First, check if the class has already been loaded
        Class c = findLoadedClass(name);
        if (c == null) {
            long t0 = System.nanoTime();
                try {
                    if (parent != null) {
                        c = parent.loadClass(name, false);
                    } else {
                        c = findBootstrapClassOrNull(name);
                } catch (ClassNotFoundException e) {
                    // ClassNotFoundException thrown if class not found

                    // from the non-null parent class loader

                if (c == null) {
                    // If still not found, then invoke findClass in order
                    // to find the class.
                    c = findClass(name);
            if (resolve) {
            return c;
The default implementation of the method searches for classes in the following order:
  1. Invokes the findLoadedClass(String) method to see if the class is already loaded.
  2. Invokes the loadClass(String) method on the parent class loader.
  3. Invoke the findClass(String) method to find the class.

How Java Class Loaders works .     How Java Class Loaders works . Reviewed by Mukesh Jha on 10:53 AM Rating: 5


Add your comment

All Right Reserved To Mukesh Jha.. Theme images by Jason Morrow. Powered by Blogger.