The ClassLoader in Java is responsible for loading class files, which contain a specific file identifier at their beginning. It loads the bytecode content into memory and converts it into runtime data structures in the method area. The ClassLoader only handles loading class files; whether they can be executed is determined by the Execution Engine.

Java's compiled .class files are loaded through the ClassLoader, which raises several important questions:

• How does the ClassLoader identify which .class files to load?
• If I manually change a regular file's extension to .class, will the ClassLoader load it?

Class files have a specific identifier at their beginning. If you compile any Java program and examine the resulting class file, you'll see the following content at the start:

The "cafe babe" sequence serves as a unique identifier for class files. The ClassLoader only processes files with this identifier, loading their bytecode content into memory and transforming it into runtime data structures in the method area.

For example, when a Car.class file is loaded by the ClassLoader, the Car Class becomes a template in memory that can be instantiated into different objects like car1, car2, car3.

One might wonder: which type of ClassLoader is used to load a Car.class file in Java? To answer this, let's examine a simple code example:

// Create a Car instance
Vehicle vehicle = new Vehicle();

// Get its ClassLoader
ClassLoader vehicleLoader = vehicle.getClass().getClassLoader();

// Display the result
System.out.println(vehicleLoader);

The output would show something like:

Now, let's look at another example with different types of classes:

// Create two different objects
Vehicle vehicle = new Vehicle();
Text text = new Text();

// Get their ClassLoaders
ClassLoader vehicleLoader = vehicle.getClass().getClassLoader();
ClassLoader textLoader = text.getClass().getClassLoader();

// Display the results
System.out.println(vehicleLoader);
System.out.println(textLoader);

The results show one as "sun.misc.Launcher$AppClassLoader@18b4aac2" and the other as "null". This difference occurs because the vehicle object represents a custom class, while text represents a system class. In other words, the ClassLoader selects different loaders based on the class being loaded, which leads to the classification of ClassLoaders.

Types of ClassLoaders

1. Bootstrap ClassLoader (BootStrap)
2. Extension ClassLoader (Extension)
3. Application ClassLoader (AppClassLoader)
4. User-defined ClassLoader

Typically, classes written by developers are loaded by the AppClassLoader, as shown in the "sun.misc.Launcher$AppClassLoader@18b4aac2" output. The "null" result for the text object indicates that it's loaded by the Bootstrap ClassLoader.

The Bootstrap ClassLoader serves as the parent for both the Extension and Application ClassLoaders. When the Bootstrap ClassLoader is used, its result is displayed as "null" because it has no parent loader.

You can verify the Bootstrap ClassLoader's role by locating the String class in the JDK:

All classes in the $JAVA_HOME/jre/lib/rt.jar path are loaded by the Bootstrap ClassLoader.

The following diagram illustrates the ClassLoader hierarchy:

1. All classes in $JAVA_HOME/jre/lib/rt.jar are loaded by Bootstrap
2. All classes in $JAVA_HOME/jre/lib/ext/*.jar are loaded by Extension
3. All classes in $CLASSPATH are loaded by the System ClassLoader (also known as Application ClassLoader)

Now, consider what happens if you create your own String class in the java.lang package:

package java.lang;

public class String {
    public static void main(String[] args) {
        System.out.println("Hello World");
    }
}

When you try to run this code, you'll encounter an error indicating that the main method cannot be found, even though it's clearly defined. This behavior is related to the double-parent delegation mechanism.

Double-Parent Delegation Mechanism

When a class receives a loading request, it first attempts to delegate this request to its parent class loader rather than loading the class itself. Each level of class loader follows this pattern, so all loading requests should eventually reach the Bootstrap ClassLoader. Only when the parent loader reports that it cannot fulfill the request (i.e., it cannot find the required class in its search path) will the child loader attempt to load the class itself.

The actual process works as follows:

1. The ClassLoader receives a loading request for the String class.
2. It first checks the Bootstrap loader for this class. Since the Bootstrap loader finds java.lang.String in rt.jar, it returns the loaded class.
3. The request never reaches the lower-level loaders, preventing the custom String class from being loaded.

This mechanism ensures that core Java classes are always loaded by the Bootstrap ClassLoader, preventing conflicts with custom implementations of standard library classes.