1. Overview
Java uses different types of class loaders to load resources during program execution. In this tutorial, we’ll explore the difference in the behavior of current and thread class loaders in Java.
2. What Does a Class Loader Do?
Java class loaders locate and load the classes required for application execution. If the requested class is dependent on any other resources, they are loaded as well.
We need appropriate class loaders for loading different types of classes whenever required by Java programs.
3. Relationship Between Class Loaders
Java class loaders follow a hierarchical relationship.
Each request to find or load a class is delegated to the respective parent class loader. If all the ancestor class loaders are unable to find a class, then the current class loader tries to locate it. Here, “current class” implies the class of the currently executing method.
This relationship between class loaders helps in maintaining the uniqueness of resources in an application. Additionally, if a class has already been loaded by a parent class loader, the child class loader doesn’t need to reload it.
4. Default Class Loaders
Class loaders load classes and resources present on their respective classpath:
- System or application class loaders load classes from the application classpath
- Extension class loaders search on the Extension classpath (JRE/lib/ext)
- Bootstrap class loader looks on the Bootstrap classpath (JRE/lib/rt.jar)
A Bootstrap or Primordial class loader is the parent of all class loaders. It loads the Java runtime – the classes required to run the JVM itself.
Current class loaders search for resources in a linear, hierarchical fashion. If a class loader can’t locate a class, it throws java.lang.ClassNotFoundException to the corresponding child class loader. The child class loader then tries to search for the class.
For scenarios where required resources aren’t found on classpaths of any of the class loaders in the hierarchy, we get error messages related to java.lang.ClassNotFoundException as the end result.
We can customize the default class loading behavior as well. We can explicitly specify the class loader while loading a class dynamically.
However, we should note that if we load the same class from different types of class loaders, these will be seen as different resources by the JVM.
5. Context Class Loaders
Apart from the default class loaders, J2SE also introduced context class loaders.
Each thread in Java has an associated context class loader.
We can access/modify the context class loader for a thread using the getContextClassLoader() and setContextClassLoader() methods of the Thread class.
The context class loader is set at the time of the creation of a thread. If not set explicitly, it defaults to the context class loader of the parent thread.
Context class loaders also follow the hierarchy model. The root class loader, in this case, is the context class loader of the primordial thread. A primordial thread is the initial thread created by the operating system.
As the application starts executing, other threads may get created. The context class loader of a primordial thread is initially set to the class loader that loads the application, i.e., the system class loader.
Suppose we don’t update the context class loader for any thread at any level of the hierarchy. As a result, we can say that by default, the context class loader for a thread is the same as the system class loader. For such scenarios, if we perform Thread.currentThread().getContextClassLoader() and getClass().getClassLoader() operations, both will return the same objects.
5.1. Handle Issues With Delegation
Context class loaders are significant when required resources aren’t present on the classpath of the default Java class loaders. Therefore, we can use context class loaders to diverge from the traditional linear delegation model.
In the hierarchical model of class loaders, resources loaded by parent class loaders are visible to the child class loaders, but not vice versa. In some scenarios, parent class loaders might need to access classes present on the classpath of child class loaders.
Context class loaders are a useful tool to make this happen. We can set the context class loader to the desired value when accessing required resources. Hence, in the above case, we can use the child thread’s context class loader and can locate the resources present at the child class loader level.
5.2. Multi-Module Environment
While setting the context class loader property, we’re basically switching the context for loading resources. Instead of searching at the current classpath, we fetch a new class loader pointing to a different classpath. This is particularly helpful if we want to load resources from a third-party module or if we are working in an environment with different class namespaces.
However, we should exercise caution here and reset the context class loader property back to the original class loader to avoid any future discrepancies.
6. Conclusion
In this article, we’ve analyzed the significance of using context class loaders to load resources not accessible via normal class loaders. We saw that we could also choose to temporarily update the context class loader for a given thread for loading required classes.
It is essential to understand the context in which the current method is working. We can have resources with the same name existing on different classpaths. Hence, while loading resources from multiple class loaders, we should exercise caution.
