How does Java classloading work, and can two classes with the same name coexist in one JVM?

• Bootstrap loader – native code, loads core java.base classes like Object and String; represented as null.
• Platform loader – loads other standard JDK modules not in the bootstrap set.
• Application loader – loads your classpath or module path; returned by ClassLoader.getSystemClassLoader().
• Parent-delegation – a loader asks its parent first; only loads itself if the parent fails. Core classes are always from Bootstrap.
• Class identity – fully-qualified name plus defining loader. Same name, different loaders, means distinct classes.
• Isolation – app servers and plugin systems use separate loaders so deployments do not clash.

How does classloading work?

Classloading happens lazily: the JVM loads a class the first time it is actively used, for example when you create an instance, call a static method, or access a static field. The lifecycle has three stages:

• Loading – finds the class bytes and creates a Class object.
• Linking – verification (bytecode safety), preparation (allocate static fields with defaults), resolution (resolve symbolic references).
• Initialization – runs static initializers and static field assignments, exactly once, thread-safe.

package com.bank.demo;

public class LoaderDemo {
    public static void main(String[] args) {
        // Bootstrap loader (null)
        System.out.println("String loader: " +
            String.class.getClassLoader()); // null

        // Application loader
        System.out.println("LoaderDemo loader: " +
            LoaderDemo.class.getClassLoader());

        // System class loader
        System.out.println("System loader: " +
            ClassLoader.getSystemClassLoader());
    }
}

String loader: null
LoaderDemo loader: jdk.internal.loader.ClassLoaders$AppClassLoader@...
System loader: jdk.internal.loader.ClassLoaders$AppClassLoader@...

What is the class loader hierarchy?

The loaders form a chain:

• Bootstrap (root, native code) loads java.base classes like java.lang.Object and java.lang.String.
• Platform loads other standard JDK modules.
• Application loads your application's classpath or module path.

How does parent delegation work?

When a loader is asked to load a class, it delegates to its parent first. Only if every ancestor fails does it try to load the class itself.

Two effects:

• Core classes are always loaded by Bootstrap, so you cannot replace java.lang.String with your own version.
• Shared classes are loaded once by the parent and shared downward, avoiding duplicates.

package com.bank.demo;

public class DelegationDemo {
    public static void main(String[] args) throws Exception {
        // The standard loadClass flow:
        // 1. Check if already loaded
        // 2. Delegate to parent
        // 3. If parent fails, call findClass

        ClassLoader appLoader = ClassLoader.getSystemClassLoader();
        Class<?> clazz = appLoader.loadClass("com.bank.demo.DelegationDemo");
        System.out.println("Loaded by: " + clazz.getClassLoader());
    }
}

Loaded by: jdk.internal.loader.ClassLoaders$AppClassLoader@...

Can two classes with the same name coexist?

Yes. A class's identity in the JVM is the pair of its fully-qualified name and the class loader that defined it. If two different loaders each load com.bank.FeePolicy, the JVM treats them as two distinct classes.

package com.bank.plugin;

import java.net.URL;
import java.net.URLClassLoader;
import java.nio.file.Path;

public class DualLoaderDemo {
    public static void main(String[] args) throws Exception {
        URL jar1 = Path.of("plugin-v1.jar").toUri().toURL();
        URL jar2 = Path.of("plugin-v2.jar").toUri().toURL();

        // Two separate class loaders
        URLClassLoader loader1 = new URLClassLoader(
            new URL[]{jar1}, null); // parent = null (bootstrap)
        URLClassLoader loader2 = new URLClassLoader(
            new URL[]{jar2}, null);

        Class<?> class1 = loader1.loadClass("com.bank.FeePolicy");
        Class<?> class2 = loader2.loadClass("com.bank.FeePolicy");

        System.out.println("Same name: " +
            class1.getName().equals(class2.getName())); // true
        System.out.println("Same class: " +
            (class1 == class2));                        // false
        System.out.println("Assignable: " +
            class1.isAssignableFrom(class2));           // false
    }
}

Same name: true
Same class: false
Assignable: false

They have separate Class objects, separate static fields, and are not assignment-compatible. Assigning an instance of one to a variable typed by the other throws ClassCastException, even though the source code is identical.

How do application servers use this for isolation?

Tomcat gives each deployed web application its own class loader. Two apps can bundle different versions of the same library without conflict. The web app loader checks its own WAR first for application classes, then delegates to the parent for core and server classes.

// Tomcat's per-app isolation:
// App1 bundles Jackson 2.14
// App2 bundles Jackson 2.17
// Each app's ClassLoader loads its own Jackson version
// They coexist as distinct classes in the same JVM

What is a class-loader leak and how does it happen?

If something outside a web app holds a reference to a class or instance from the app's loader, the loader cannot be garbage-collected on undeploy. This causes a class-loader leak that slowly exhausts metaspace.

Common causes:

• A ThreadLocal in a shared thread pool holding an app-loaded object.
• A JDBC driver registered in a parent-level DriverManager.
• A static cache in a shared library holding references to app classes.

// Example: ThreadLocal leak
// Shared thread pool thread has a ThreadLocal holding an app object
// On undeploy, the ThreadLocal keeps the app's ClassLoader alive
// Metaspace grows with each redeployment

// Fix: clear ThreadLocals on undeploy
// Tomcat's memory leak detection warns about this

How does the module system interact with classloading?

In the module system, classes belong to modules, and module boundaries control accessibility. The module graph adds another layer of encapsulation on top of class loaders. A module can exports packages to control which other modules can access its classes.

// module-info.java
module com.bank.core {
    exports com.bank.model;
    exports com.bank.service;
}

What about custom class loaders?

You create a custom class loader by extending ClassLoader and overriding findClass. This is used in plugin systems, hot-reloading frameworks, and sandboxed execution.

package com.bank.plugin;

import java.io.IOException;
import java.nio.file.Files;
import java.nio.file.Path;

public class PluginClassLoader extends ClassLoader {
    private final Path pluginDir;

    public PluginClassLoader(Path pluginDir, ClassLoader parent) {
        super(parent);
        this.pluginDir = pluginDir;
    }

    @Override
    protected Class<?> findClass(String name) throws ClassNotFoundException {
        String fileName = name.replace('.', '/') + ".class";
        Path classFile = pluginDir.resolve(fileName);
        try {
            byte[] bytes = Files.readAllBytes(classFile);
            return defineClass(name, bytes, 0, bytes.length);
        } catch (IOException e) {
            throw new ClassNotFoundException(name, e);
        }
    }
}

What should a senior engineer know?

Understanding that identity equals name plus loader is the key to both using isolation deliberately and debugging when it goes wrong. The confusing error "FeePolicy cannot be cast to FeePolicy" always means two different loaders. Diagnosing class-loader leaks is a classic production task. When a loader and all its classes become unreachable, they can be garbage-collected, which is how undeploying an app frees its classes.