I’m an altruist who’s amazed by beautiful things out of my reach. My zeal increases whenever I come to know them better. One of them is the magical land of classloaders, the A-Team that loads all the classes in the JVM. Enough with the twaddling, lets get to business.

Classloaders are pivotal in the lifecycle of a JVM. Like everything in an object oriented language, each Classloader is an object – an instance of class that extends java.lang.ClassLoader. 

Let’s look at what the particular class has got. (An extract from ZeroTurnaround’s whitepaper)

So it’s an abstract class. The major methods we have above are loadClass and defineClass. 

Define class takes in the byte code for a compiled class and returns a Class instance. The byte code can be loaded from the disk or a remote location.

LoadClass is the superstar. It is responsible for loading the class to the JVM. The parameter to be passed is the Class name in the standard enforced by JAVA.(roughly the classname with the package structure)

So, making matters smooth, if you already have a class to be loaded, you can straightaway use the loadClass method, or else you’ll have to use the defineClass first. See the example

There are a couple of things that can me made out from the example above. Understanding them is critical while understanding Classloaders.

1. Every class has a reference to it’s corresponding static class variable. The class instance was created when this class was initially loaded. 
2. The static class variable has a reference to it’s ClassLoader. It can be seen in the classloader is fetched using the getter and consequently the loadClass method is invoked.
3. Since the class is already available, it can be easily loaded using the loadClass method. Otherwise, we would have to use defineClass method.

ClassLoader Hierarchy

It’s not just one classloader that’s behind the play. Let’s split them into three.

1. Bootstrap Classloader
2. Extension Classloader
3. System Classpath Classloader

The bootstrap class loader kicks in first and loads all the java standard classes. Then comes the extension class loader which uses the java extension functionality which loads from the ‘java.ext.dirs’ directory. I wish to write more about the extension framework, but I will save it for later. As far as a developer is concerned, the System classpath loader is the most important one. This loads the classes from the defined classpath. This will include all the user created classes ( minus the user created libraries which should ideally go under extension ).

As it’s evident from the figure above, all the classloader has a parent except the Bootstarp classloader which occupies the highest level in the hierarchy. Whenever there is need for loading a class, the classloader follows a delegation approach. The system classpath loader sees if it can be loaded by extension classloader. If extension class loader can’t, the extension loaded delegates it to the bootstrap class loader.

Having said this order of delegation, from classpath to extension to bootstrap, i have to add that the order is reversed in the case of enterprise applications. I’ll save that discussion for sometime later.