I have been working with Java for many years now. The major black spot (from a developer's point of view) I see for any java application is Class Loading Internals. I always wonder how jdk and jvm works together to provide an environment for an application to run. What works behind the scene to provide all the resource that our small written code works? I will try to answer some of question in this article.
In below article I am going to explain in below sequence
· What is a class loader
· What is the difference between a class and Data
· How class loader works
· Java Class loader types
· Custom Class Loader
· Conclusion
What is a class loader?
A class loader is part of java runtime environment that dynamically loads java classes into java virtual machine.
The class loader is responsible for locating libraries, reading their contents, and loading the classes contained within the libraries.
This loading is typically done "on demand", in that it does not occur until the class is called by the program. A class with a given name can only be loaded once by a given class loader.
In other words they are responsible to feed your java program with all dependent jars/classes required to execute your program as and when needed.
Also, these Java classes aren’t loaded into memory all at once, but when required by an application. This is where class loaders come into the picture. They are responsible for loading classes into memory.
What is the difference between a class and Data?
A class represents the code to be executed, whereas data represents the state associated with that code. State can change; code generally does not.
When we associate a particular state to a class, we have an instance of that class. So different instances of the same class can have different state, but all refer to the same code.
In Java, a class will usually have its code contained in a .class file, though there are exceptions.
Nevertheless, in the Java runtime, each and every class will have its code also available in the form of a first-class Java object, which is an instance of java.lang.Class. Whenever we compile any Java file, the compiler will embed a public, static, final field named class, of the type java.lang.Class, in the emitted byte code. Since this field is public, we can access it using dotted notation, like this:
java.lang.Class klass = Myclass.class;
Once a class is loaded into a JVM, the same class will not be loaded again.*
How java class loading works!
In this section first we understand the type of class loader available in java, their primary source to load classes and major responsibilities and in later section we will see how they actually works.
In Java each and every class is loaded by an instance of java.lang.ClassLoader. Developer can create their own class loaders by extending this class. We will see this in detail in last section.
The story starts when we run any java application(jvm started by typing java MyMainClass), the bootstrap class loader is responsible for loading key java classes like java.lang.Object and other runtime code into memory(mainly from rt.jar) The runtime classes are packaged inside a jar present under JRE\lib\rt,jar.
Now since you have all the bare minimum or essential classes to run java program, its time to load the classes required for the specific program that we are trying to run.
So next comes the java extension class loader. We can store extension libraries, those provide features that go beyond the code runtime code. This class loader is responsible for loading all .jar files present under java.ext.dirs path.
And the last but most important class loader from a developer’s point of view is the Appclassloader. The application class loader is responsible for loading all of the classes kept in the path corresponding to the java.class.path system property.
Now let’s understand how class loader works?
All class loaders except bootstrap class loader have a parent class loader. Moreover all the class loaders themselves a subclass of java.lang.Classloader. The most important aspect is to correctly set the parent class loader. The parent class loader for any class loader is the class loader instance that loader that class loader (point to be noted that a class loader is itself a class).
A class is requested out of a class loader using the loadClass() method. Following is the code snippet if this method:
protected synchronized Class<?> loadClass
(String name, boolean resolve) throws ClassNotFoundException {
// First check if the class is already loaded
Class c = findLoadedClass(name);
if (c == null) {
try {
if (parent != null) {
c = parent.loadClass(name, false);
} else {
c = findBootstrapClass0(name);
}
} catch (ClassNotFoundException e) {
// If still not found, then invoke
// findClass to find the class.
c = findClass(name);
}
}
if (resolve) {
resolveClass(c);
}
return c;
}
To set the parent class loader, we have two ways to do so in the ClassLoader constructor. Let’s see them in below java class loader example.
public class MyClassLoader extends ClassLoader{
public MyClassLoader(){
super(MyClassLoader.class.getClassLoader());
}
}
public class MyClassLoader extends ClassLoader{
public MyClassLoader(){
super(getClass().getClassLoader());
}
}
There are three important features of class loaders.
Delegation Model
Class loaders follow the delegation model where on request to find a class or resource, a ClassLoader instance will delegate the search of the class or resource to the parent class loader.
Let’s say we have a request to load an application class into the JVM. The system class loader first delegates the loading of that class to its parent extension class loader which in turn delegates it to the bootstrap class loader.
Only if the bootstrap and then the extension class loader is unsuccessful in loading the class, the system class loader tries to load the class itself.
Unique Classes
As a consequence of the delegation model, it’s easy to ensure unique classes as we always try to delegate upwards.
If the parent class loader isn’t able to find the class, only then the current instance would attempt to do so itself.
Visibility
In addition, children class loaders are visible to classes loaded by its parent class loaders.
For instance, classes loaded by the system class loader have visibility into classes loaded by the extension and Bootstrap class loaders but not vice-versa.
To illustrate this, if Class A is loaded by an application class loader and class B is loaded by the extensions class loader, then both A and B classes are visible as far as other classes loaded by Application class loader are concerned.
Class B, nonetheless, is the only class visible as far as other classes loaded by the extension class loader are concerned.
What all class loader present in Java
In first step lets first see how different classes are getting loaded by different class loaders using a simple example:
public void printClassLoaders() throws ClassNotFoundException {
System.out.println("Classloader of this class:" + PrintClassLoader.class.getClassLoader());
System.out.println("Classloader of Logging:" + Logging.class.getClassLoader());
System.out.println("Classloader of ArrayList:" + ArrayList.class.getClassLoader());
}
Output:
Class loader of this class:sun.misc.Launcher$AppClassLoader@18b4aac2
Class loader of Logging:sun.misc.Launcher$ExtClassLoader@3caeaf62
Class loader of ArrayList:null
As we can see, there are three different class loaders here; application, extension, and bootstrap (displayed as null).
The application class loader loads the class where the example method is contained. An application or system class loader loads our own files in the classpath.
Next, the extension one loads the Logging class. Extension class loaders load classes that are an extension of the standard core Java classes.
Finally, the bootstrap one loads the ArrayList class. A bootstrap or primordial class loader is the parent of all the others.
However, we can see that the last out, for the ArrayList it displays null in the output. This is because the bootstrap class loader is written in native code, not Java – so it doesn’t show up as a Java class. Due to this reason, the behavior of the bootstrap class loader will differ across JVMs.
Let’s now discuss more in detail about each of these class loaders.
Bootstrap Class Loader
Java classes are loaded by an instance of java.lang.ClassLoader. However, class loaders are classes themselves. Hence, the question is, who loads the java.lang.ClassLoader itself?
This is where the bootstrap or primordial class loader comes into the picture.
It’s mainly responsible for loading JDK internal classes, typically rt.jar and other core libraries located in $JAVA_HOME/jre/lib directory. Additionally, Bootstrap class loader serves as a parent of all the other ClassLoaderinstances.
This bootstrap class loader is part of the core JVM and is written in native code as pointed out in the above example. Different platforms might have different implementations of this particular class loader.
Extension Class Loader
The extension class loader is a child of the bootstrap class loader and takes care of loading the extensions of the standard core Java classes so that it’s available to all applications running on the platform.
Extension class loader loads from the JDK extensions directory, usually $JAVA_HOME/lib/ext directory or any other directory mentioned in the java.ext.dirs system property.
System Class Loader
The system or application class loader, on the other hand, takes care of loading all the application level classes into the JVM. It loads files found in the classpath environment variable, -classpath or -cp command line option. Also, it’s a child of Extensions classloader.
Custom Class Loaders
In this section let’s understand how to create a custom loader?
Custom class loaders are really useful in case a java program needs to load some external/third party code in your java program that cannot be included in your java program directly or cannot be added in classpath.
Let’s take an example of loading some classes from a FTP server:
public class CustomClassLoader extends ClassLoader {
public CustomClassLoader(ClassLoader parent
) {
super(parent
);
}
public Class
getClass(String name
) throws ClassNotFoundException
{
byte[] b
= loadClassFromFTP
(name
);
return defineClass(name
, b
, 0, b
.length);
}
@Override
public Class
loadClass(String name
) throws ClassNotFoundException
{
if (name
.startsWith("in.thinkwithjava")) {
System
.out.println("Loading Class from Custom Class Loader");
return getClass(name
);
}
return super.loadClass(name
);
}
private byte[] loadClassFromFTP(String fileName
) { // Returns a byte array from specified file.
}
}
In above example, we defined a custom class loader that extends default class loader and load class from in.thinkwithjava package.
We set the parent class loader in the constructor. Then we load the class using FTP specifying a fully qualified class name as an input
Now let’s understand some essential methods of java.lang.Classloader in order to understand the working properly.
The loadClass() Method
public Class loadClass(String name, boolean resolve) throws ClassNotFoundException {
This method is responsible for loading the class given a name parameter. The name parameter refers to the fully qualified class name.
This method serves as an entry point for the class loader.
The default implementation of the method searches for classes in the following order:
1. Invokes the findLoadedClass(String) method to see if the class is already loaded.
2. Invokes the loadClass(String) method on the parent class loader.
3. Invoke the findClass(String) method to find the class.
The defineClass() Method
protected final Class defineClass(String name, byte[] b, int off, int len)
throws ClassFormatError
This method is responsible for the conversion of an array of bytes into an instance of a class. And before we use the class, we need to resolve it.
In case data didn’t contain a valid class, it throws a ClassFormatError.
Also, we can’t override this method since it’s marked as final.
The findClass() Method
protected Class findClass(
String name) throws ClassNotFoundException
This method finds the class with the fully qualified name as a parameter. We need to override this method in custom class loader implementations that follow the delegation model for loading classes.
Also, loadClass() invokes this method if the parent class loader couldn’t find the requested class.
The default implementation throws a ClassNotFoundException if no parent of the class loader finds the class.
The getParent() Method
public final ClassLoader getParent()
This method returns the parent class loader for delegation.
The getResource() Method
public URL getResource(String name)
This method tries to find a resource with the given name. It will first delegate to the parent class loader for the resource. If the parent is null, the path of the class loader built into the virtual machine is searched.
If that fails, then the method will invoke findResource(String) to find the resource. The resource name specified as an input can be relative or absolute to the class path.
It returns an URL object for reading the resource, or null if the resource could not be found or if the invoker doesn’t have adequate privileges to return the resource. It’s important to note that Java loads resources from the classpath.
Finally, resource loading in Java is considered location-independent as it doesn’t matter where the code is running as long as the environment is set to find the resources.
In last section we had a brief explanation of how to create a custom one with example and seen the various methods.
Conclusion
Class loader are essential and key feature for java programs. We’ve provided a good introduction as part of this article.
We talked about different types of class loaders namely – Bootstrap, Extensions and System class loaders. Bootstrap serves as a parent for all of them and is responsible for loading the JDK internal classes. Extensions and system, on the other hand, loads classes from the Java extensions directory and class path respectively.
Then we talked about how class loaders work and we discussed some features such as delegation, visibility, and uniqueness.
Thanks for reading!
