Why is ClassLoader's cache checked in ascending sequence while class-loading befalls in descending sequence?
Note: The ClassLoader Delegation Hierarchy Model always functions in the order Application ClassLoader->Extension ClassLoader->Bootstrap ClassLoader. The Bootstrap ClassLoader is always given the higher priority, next is Extension ClassLoader and then Application ClassLoader.
A Java Class is stored in the form of byte code in a . class file after it is compiled. The ClassLoader loads the class of the Java program into memory when it is required. The ClassLoader is hierarchical and so if there is a request to load a class, it is delegated to the parent class loader.
The Java Class Loader is a part of the Java Runtime Environment that dynamically loads Java classes into the Java Virtual Machine. Usually classes are only loaded on demand. The Java run time system does not need to know about files and file systems as this is delegated to the class loader.
ClassLoader in Java is a class that is used to load class files in Java. Java code is compiled into a class file by javac compiler and JVM executes the Java program, by executing byte codes written in the class file. ClassLoader is responsible for loading class files from file systems, networks, or any other source.
ClassLoader in Java works on three principle: delegation, visibility and uniqueness. 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 can not 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.
In other words as described here:
The class loaders in Java are organized in a tree. By request a class loader determines if the class has already been loaded in the past, looking up in its own cache. If the class is present in the cache the CL returns the class, if not, it delegates the request to the parent. If the parent is not set (is Null) or can not load the class and throws a ClassNotFoundException the classloader tries to load the class itself and searches its own path for the class file. If the class can be loaded it is returned, otherwise a ClassNotFoundException is thrown. The cache lookup goes on recursively from child to parent, until the tree root is reached or a class is found in cache. If the root is reached the class loaders try to load the class and unfold the recursion from parent to child. Summarizing that we have following order:
- Cache
- Parent
- Self
This mechanism ensures that classes tending to be loaded by class loaders nearest to the root.
It is purely a matter of efficiency. If you forget about the cache, the order of classloading ensures that Java system classes always take precedence over application classes and that a class can only be loaded by one classloader in a chain. So there is no class that is in more than one cache and so the order of searching the caches makes no functional difference.
In other words, you could search the bootloader cache followed by the extension classloader cache followed by the system classloader cache and then start trying to load the classes and the end result would be exactly the same. To do this would require an extra API to search for a loaded class and would bring little benefit as searching a cache is a very quick operation.
Note that classes can be loaded by more than one classloader, but not if they are in a loader->parent chain.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With