Classloader delegation model was first introduced in JDK 1.2. Class loaders are organized in heirarchical model like a tree, with bootstrap loader as the root of the tree. Every user defined class loader is assigned a parent loader when it is created. Remember that it is only the bootstrap class loader that does not have any parent class loader that is why it is the root of the class loaders in heirarchical model.
Whenever there is a request to load a class to a class loader, the class loader first delegates the request to it parent class loader. If the parent class loader is failing to do it may delegate the request to its own parent class loader if any otherwise the child class loader who delegated the request initially would try to load the class. If none of the class loaders are able to load the class then the JVM will throw classNotFoundException or NoClassDefFoundError. ClassNotFoundException is thrown when tried to load a class with Class.forName(“MyClass”) and class definition is not found. NoClassDefFoundError is thrown in a scenario when a class definition was available during compilation but unable to find during runtime.
However this delegation is not followed stringently. As per Java Servlet Specification 2.3 Class loaders in a servlet container are required to load servlets by themselves first, failing to do so should delegate the request to it’s immediate parent class loader.
Whenever you start a java application it is the bootstrap classloader that loads the core classes from java.lang and javax.* package into the JVM. Next comes the extension class loader that loads classes from the JRE’s extension directories. At the end comes the system class loader that loads class from the system class path. Note that the identity of a java class is not only uniquely identified by it package name but also by the class loader that loads it into the VM.
Posts Tagged Class Loader
