What is a Java ClassLoader?

The Java Classloader is a part of the JRE (Java Runtime Environment) that dynamically loads Java classes into the JVM (Java Virtual Machine). In particular, a Java program, unlike one written in C or C++, isn't a single executable file, but instead is composed of many individual class files, each of which corresponds to a single Java class. Normally classes are only loaded on demand. This means, these Java class files are not loaded into memory all at once, but rather are loaded on demand, as needed by the program (Class Loader). Class Loader is a component with the Java Execution Engine which loads the Binary data from the .class files available in the classpath into the Method Area . Loading of a class into the method area occurs only the first time when the class is referenced with in the running Java application. For all other references the data is reused from the method area, unless the class has been UNLOADED .

ClassLoader in Java works on three principle:

  1. Delegation
  2. Visibility
  3. Uniqueness
The Delegation principle forward request of class loading to parent class loader and only loads the class, if parent is not able to find or load class. Visibility principle allows child class loader to see all the classes loaded by parent ClassLoader, but parent class loader cannot see classes loaded by child. Uniqueness principle allows to load a class exactly once, which is basically achieved by delegation and ensures that child ClassLoader doesn't reload the class already loaded by parent. All JVM (Java virtual machines) include one class loader that is embedded in the virtual machine. This embedded loader is called the primordial class loader . It is somewhat special because the VM (virtual machine) assumes that it has access to a repository of trusted classes which can be run by the virtual machine without verification. When the Java Virtual Machine is started, three class loaders are used:
  1. Bootstrap class loader
  2. Extensions class loader
  3. System class loader
The bootstrap class loader loads JDK internal classes, typically loads rt.jar and other core classes for example java.lang.* package classes. The extensions class loader loads classes from the JDK extensions directory, usually $JAVA_HOME/lib/ext directory. 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.

Building a SimpleClassLoader

A class loader starts by being a subclass of java.lang.ClassLoader . The only abstract method that must be implemented is loadClass(). The flow of loadClass() is as follows:
  1. Verify class name.
  2. Check to see if the class requested has already been loaded.
  3. Check to see if the class is a "system" class.
  4. Attempt to fetch the class from this class loader's repository.
  5. Define the class for the Virtual Machine.
  6. Resolve the class.
  7. Return the class to the caller.

How the very first class loaded?

Class loaders are hierarchical. The initial class is loaded with the help of public static main() method declared in your class. All the subsequently loaded classes are loaded by the classes, which are already loaded and running.

Classloader hierarchy

Whenever a new JVM is started the bootstrap classloader is responsible to load key Java classes (from java.lang package) and other runtime classes to the memory first. The bootstrap classloader is a parent of all other classloaders. Consequently, it is the only one without a parent. Second phase comes the extension classloader. It has the bootstrap classloader as parent and is responsible for loading classes from all .jar files kept in the java.ext.dirs path–these are available regardless of the Java Virtual Machine's classpath. The third and most important classloader from a developer's perspective is the system classpath classloader, which is an immediate child of the extension classloader. It loads classes from directories and jar files specified by the CLASSPATH environment variable, java.class.path system property or -classpath command line option. Most Java programmers will never need to explicitly use class loaders (except to load resources so that it still works when they're bundled in JARs), let alone write their own. ClassLoaders are used in very large systems and server applications to do things like:
  1. Modularize a system and load, unload and update modules at runtime
  2. Use different versions of an API library (e.g. an XML parser) in parallel
  3. Isolate different applications running within the same JVM (ensuring they don't interfere with each other, e.g. through static variables)
Class Loaders are a functional component of Java Virtual Machine, which loads class data from the .class file or from over the network in to the Method Area in Heap . Each class loader has it's own name space and classes invoked by a particular class loader gets into it's name space. Classes invoked by two different class loaders will not have visibility over each other, resulting in enhanced security. Class loader parent child delegation mechanism ensures java api classes could never be hacked by unauthorized code. This is because class loaders exist, the Java run time does not need to know anything about files and file systems when running Java programs. Moreover, Java ClassLoader is written in the Java language itself. This means that it's easy to create your own ClassLoader without having to understand the finer details of the JVM (Java Virtual Machine).