Monday, 2 July 2012

A closer look at the Class Loader


What is a Class Loader?

Class loader is a part of JRE that loads the java classes into your JVM so that JVM need not bother about reading .class files for the classes needed at runtime.

Why is Class loader needed?

When we talk about Java, every piece of code is written in a .java file. Which is a plain text file. This gets complied by a java compiler and creates one or more .class files which we call as byte code. Some group of these .class files are usually archived using jar mechanism producing a .jar file (rt.jar from core java library is an example of jar file which contains core classes). When JVM needs a class for execution, it cannot open the jar file and find out the correct .class file and use it. Class loader is responsible for loading this class into JVM.

Types of class loaders:

1. Bootstrap Class Loader
This class loader is a native class loader. Hence it may have different implementations for different JVMs. This loader loads the classes from the core java library i.e. jars from $JAVA_HOME/lib directory. So all classes from packages like java.lang, java.io, java.util will be available to your JVM with help this class loader.

2. Extensions Class Loader
This loader loads the classes from the jars available in extensions directories ($JAVA_HOME/lib/ext). This can also load the jars from other directories which are defined in java.ext.dirs system property. It is implemented by sun.misc.Launcher$ExtClassLoader.

3. System Class Loader
This loads classes form java.class.path system property or $CLASSPATH env variable. This is implemented by sun.misc.Launcher$AppClassLoader.

4. Custom Class Loader
A custom class loader is needed when classes from some custom repositories need to be loaded. Any number of custom class loaders can be present in a JVM. The best example is a web application under tomcat might have a bunch of jar files in WEB-INF/lib directory. Tomcat creates custom class loader to load the classes from those jar files.

Deligation of class loaders

Here is the heirarchy of the class loaders: Custom -> System -> Extensions -> Bootstrap

When a class is requested by JVM, first it goes to all custom class loaders (if custom class loader exists). Each custom class loader will try to load the class by itself or delegates to its parent class loader (System class loader). System class loader also will try to load by its own or delegates to its parent. This way the delegation goes till the bootstrap loader and the delegation stops here. Custom class loader is an optional entity. If there is no custom class loader found, the above said process will start from System class loader. If the class is not found by any of the above class loaders, a ClassNotFoundException or NoClassDefFoundError will be thrown.


Class Uniqueness

class a.Test loaded by class loader CL1 and class a.Test loaded by class loader CL2 are not same even though they are in same JVM. Class uniqueness is defined by class name, package name and the class loader.


References



Hope you enjoyed this post on garbage collection. Feel free to comment on this. Thank you.









1 comment: