By Rafael del Nero, Java Developer, InfoWorld |Tease your mind and test your learning, with these quick introductions to challenging concepts in Java programming.Java Class loaders are a component of the Java virtual machine (JVM) and are responsible for loading Java classes into memory at runtime. When a Java program is executed, one or more class loaders locate and load all the classes that are needed to run the program.A Java class loader works by converting a class file into a Java class that can be executed by the JVM. The three primary types of class loaders in Java are as follows:Class loaders also are able to load classes dynamically at runtime, which allows Java programs to be more flexible and adaptable. This feature is particularly useful for applications that need to load new classes on demand, or that need to load classes from remote locations or over a network. Overall, Java class loaders are a critical component of the JVM that enables Java programs to load and execute classes dynamically at runtime.I've given an overview of the three main types of class loaders. In this section, we'll go over each one in more detail. To start, take a look at this diagram of Java class loaders interacting in a Java program.Figure 1. Java class loaders in a Java program.Notice that the process to start loading a class begins with the application class loader. Next, it goes to the extension class loader, and finally to the bootstrap class loader. That's the initial class search. If the class is not found, the class search returns to the extension class loader for another search. If the class is still not found, the process tries again using the application class loader. If none of the searches finds the class, then the program throws a ClassNotFoundExecption.Now, let's look at each of the class loaders in more detail.Also known as the primordial class loader, this is the class loader where the search starts. The bootstrap class loader is responsible for loading core Java classes such as java.lang.Object and java.lang.String. It is implemented in native code and classes are located in the $JAVA_HOME/lib directory.There were some important changes to class loaders between Java 8 and Java 9. For example, in Java 8, the bootstrap class loader was located in the Java Runtime Environment's rt.jar file. In Java 9 and subsequently, the rt.jar file was removed.Moreover, Java 9 introduced the Java module system, which changed how classes are loaded. In the module system, each module defines its own class loader, and the bootstrap class loader is responsible for loading the module system itself and the initial set of modules. When the JVM starts up, the bootstrap class loader loads the java.base module, which contains the core Java classes and any other modules that are required to launch the JVM.The java.base module also exports packages to other modules, such as java.lang, which contains core classes like Object and String. These packages are then loaded by the bootstrap class loader.In the following code example, we'll use the getClassLoader() method on the String class to get its class loader. Since the String class is one of the core Java classes, we'll get a reference to the bootstrap class loader.We'll print out the name of the class loader using the toString() method. When we run the code, we should see output similar to what's shown in Listing 1.The output is null because the bootstrap class loader has no parent class loader.In Java 9 and later versions, the extension class loader was removed from the JVM. It was used in earlier versions of Java to load classes from the extension directory, which was typically located in the JRE/lib/ext directory.Instead of the extension class loader, Java 9 and later versions use the java.lang.ModuleLayer class to load modules from the extension directory. The extension directory is now treated as a separate layer in the module system, and modules in the extension directory are loaded by the extension layer's class loader.Here's a demonstration of the extension layer's class loader at work:In this example, we obtain a reference to the extension layer using the ModuleLayer.boot().findLayer("java.ext") method. We then obtain a reference to the extension layer's class loader using the ClassLoader getClassLoader() method. We print out the parent class loader, which should be the platform class loader.Finally, we try loading the com.google.gson.Gson class using the Class.forName() method and passing the extension class loader as the class loader argument. Since the com.google.gson package is part of the Gson library, which is installed in the extension directory, the Gson class should be loaded by the extension layer's class loader. We print out the class loader that loaded the Gson class, which should be the extension layer's class loader.Note that in Java 9 and later versions, it is recommended to use modules instead of the extension mechanism to share code between applications. The extension mechanism is still available for backward compatibility with older applications, but it is not recommended for new code.The Application class loader (also called the system class loader) loads classes from the application's classpath. The classpath is a list of directories and JAR files that the JVM searches to find a class.The application class loader is a standard Java class that loads classes from the directories and JAR files listed in the CLASSPATH environment variable or the -classpath command-line option. It loads the first class it finds if there are multiple versions.The application class loader is the last class loader to search for a class. If it can't find it, the JVM throws a ClassNotFoundException. This class loader can also delegate class loading to its parent class loader, the extension class loader.Aside from loading classes from the classpath, the application class loader also loads classes generated at runtime, like those created by the Java Reflection API or third-party libraries that use bytecode generation.The application class loader is important because it lets developers easily use third-party libraries and modules in their applications.The code example in Listing 3 demonstrates how to get the application class loader using the ClassLoader.getSystemClassLoader() method.In this example, we get the application class loader by calling the ClassLoader.getSystemClassLoader() method. We then use the application class loader to load the java.util.ArrayList class. If the class is found and loaded successfully, we print its name to the console. If the class is not found, we print an error message.Note that in a real-world application, you would typically use the application class loader implicitly, without needing to explicitly get a reference to it. This class loader is responsible for loading classes and resources from the application's own JAR files and from third-party libraries on the classpath, so it is used automatically whenever you reference a class or resource in your code.There are just a few rules for working with Java class loaders. Knowing them will make your work simpler and more effective.The delegation model in Java allows for loading classes flexibly and dynamically at runtime. This is useful in environments where the class loading requirements are unknown at compile-time.For instance, in an application server, different applications may need different versions of the same class. The class loader delegation model makes it possible to meet these requirements without causing conflicts.Class loaders in Java can have varying levels of visibility, which determines their ability to find and load classes from other class loaders. There are three levels of visibility:The level of visibility depends on the class loader hierarchy and the classpath, and it can have significant implications for application behavior. It's important to consider the visibility model used in an application to ensure that classes are loaded correctly and that classloading conflicts are avoided.Java class loaders keep different versions of the same class in separate namespaces, which allows for creating multiple instances of a class with different versions. This is useful for web applications that need to load shared libraries without conflicts.However, this feature can cause issues if not used carefully. If a class is loaded by two different class loaders, the JVM will treat them as separate classes, and objects created from them will not be interchangeable. This can lead to unexpected behavior if these objects are passed between methods expecting objects created by different class loaders.To avoid these issues, it is recommended to use a single class loader to load classes whenever possible. When multiple class loaders are used, take extra care to ensure that objects are not passed between classes with different namespaces.Java's ClassLoader class has the following main methods:Here's an example using the loadClass() method to load a class by name at runtime:In this example, we first get the system class loader (also known as the application class loader) using the getSystemClassLoader() method. Then, we use the loadClass() method to load the java.lang.String class. Finally, we print the name of the loaded class using the getName() method. When we run this code, we should see the following output:It's important to understand how the Java class loaders work. You never know when you will have to fix a low-level issue in your Java application, with a framework, or even with the Java language itself.Knowing the fundamentals of class loaders can make the difference for you in your day-to-day programming. If you work directly in the Java language, knowing the ins and outs of Java class loaders is essential.Here are the key points to remember when working with Java class loaders:Understanding the different types of class loaders is important for Java developers. The more we know, the more we can control how classes are loaded into the JVM and manage dependencies between different components of our applications.Next read this:Copyright © 2023 IDG Communications, Inc.Copyright © 2023 IDG Communications, Inc.