Class Loading & Bytecode Verification

public class Main {
    public static void main(String[] args) {
        ClassLoader loader = Main.class.getClassLoader();
        System.out.println(loader);  // typically: jdk.internal.loader.ClassLoaders$AppClassLoader

        ClassLoader stringLoader = String.class.getClassLoader();
        System.out.println(stringLoader);  // null, since String is loaded by the Bootstrap loader
    }
}

Common follow-ups: Why does String.class.getClassLoader() return null instead of an actual ClassLoader instance?;What determines which of the three built-in class loaders is responsible for loading a particular class?

// Simplified conceptual illustration of delegation
public class MyClassLoader extends ClassLoader {
    @Override
    protected Class<?> loadClass(String name, boolean resolve) throws ClassNotFoundException {
        // Default ClassLoader.loadClass() already implements delegation:
        // 1. Check if already loaded
        // 2. Delegate to parent first
        // 3. Only if parent fails, attempt findClass() locally
        return super.loadClass(name, resolve);
    }
}

Common follow-ups: How would you deliberately break parent delegation (and why might a plugin/module system need to)?;What security guarantee does this model specifically provide against classpath-based attacks?

public class PluginClassLoader extends URLClassLoader {
    public PluginClassLoader(URL[] urls, ClassLoader parent) {
        super(urls, parent);
    }
}

// Dynamically load a plugin JAR at runtime
URL pluginUrl = new File("plugins/my-plugin.jar").toURI().toURL();
PluginClassLoader loader = new PluginClassLoader(new URL[]{pluginUrl}, Main.class.getClassLoader());
Class<?> pluginClass = loader.loadClass("com.example.MyPlugin");
Object plugin = pluginClass.getDeclaredConstructor().newInstance();

// To allow unloading: discard ALL references to loader, pluginClass, and any instances it created

Common follow-ups: What specifically prevents a ClassLoader and its loaded classes from being garbage collected, and how do you diagnose a classloader leak in a running application?;How does OSGi's module system build on custom class loading to provide more robust plugin isolation?

public class Config {
    static { System.out.println("Static initializer running"); }
    static int value = computeValue();

    static int computeValue() {
        System.out.println("Computing static value");
        return 42;
    }
}

// Config class is LOADED and LINKED when referenced, but INITIALIZATION
// (running the static block and computeValue()) happens lazily on first active use:
System.out.println("Before first use");
int v = Config.value;  // triggers initialization HERE, prints both messages first

Common follow-ups: What specific actions count as "active use" triggering initialization, versus actions that don't?;Why does bytecode verification exist as a distinct phase, and what kinds of invalid bytecode does it catch?

// Conceptually, the verifier catches things like this at the bytecode level
// (this specific example wouldn't compile via javac, but illustrates what verification guards against
// if bytecode were maliciously hand-crafted to bypass the compiler)

// Pseudocode of an invalid bytecode sequence the verifier would reject:
// push an int onto the operand stack
// attempt to invoke a method expecting a String argument -- TYPE MISMATCH, rejected

Common follow-ups: Why is verification necessary even for bytecode produced by a trusted compiler like javac?;What is the performance cost of bytecode verification, and can it be selectively disabled (and why is that risky)?

// ClassNotFoundException -- explicit runtime lookup of a class that doesn't exist anywhere
try {
    Class.forName("com.example.NonExistentClass");
} catch (ClassNotFoundException e) {
    // handle: the class genuinely isn't found by name
}

// NoClassDefFoundError -- typically NOT caught explicitly; indicates a packaging/classpath problem
// e.g., a dependency present at compile time but missing from the deployed runtime classpath

Common follow-ups: Why is NoClassDefFoundError an Error rather than an Exception, and what does that classification imply?;What's the most efficient way to diagnose exactly which JAR/dependency is missing when this occurs?

// Conceptual illustration: same class name, different loaders = different types
ClassLoader loader1 = new URLClassLoader(urls, null);
ClassLoader loader2 = new URLClassLoader(urls, null);

Class<?> classFromLoader1 = loader1.loadClass("com.example.MyClass");
Class<?> classFromLoader2 = loader2.loadClass("com.example.MyClass");

System.out.println(classFromLoader1 == classFromLoader2);  // false! Different Class objects entirely
// An instance created via loader1's class CANNOT be cast to loader2's version of the same-named class

Common follow-ups: How do application servers like Tomcat use this ClassLoader-per-webapp isolation deliberately as a feature?;What debugging technique would you use to confirm two objects are instances of 'the same class' loaded by different ClassLoaders?

// module-info.java
module com.example.myapp {
    requires java.sql;
    exports com.example.myapp.api;      // publicly usable by other modules
    // com.example.myapp.internal is NOT exported -- inaccessible outside this module
}

Common follow-ups: What is the difference between exports and opens in a module-info.java file?;How does JPMS handle backward compatibility with libraries still built for the traditional unnamed classpath module?

# Error at startup:
# java.lang.LayerInstantiationException: Package com.example.shared
# in both module com.lib.a and module com.lib.b

# Resolution: place conflicting JARs on the classpath instead of module path
java --class-path lib-a.jar:lib-b.jar --module-path myapp.jar --module com.example.myapp/com.example.Main

Common follow-ups: Why does JPMS forbid split packages so strictly rather than trying to merge or pick one automatically?;What's the difference in split-package handling between the module path and the traditional classpath?

# Historically used (now deprecated/ineffective in modern JVMs):
java -Xverify:none -jar myapp.jar

# Modern JVMs print a warning and IGNORE this flag entirely as of Java 13+:
# "Warning: -Xverify:none is deprecated and will likely be removed in a future release."

Common follow-ups: What legitimate startup-performance alternatives exist instead of disabling verification (like Class Data Sharing/CDS)?;Why did the JDK team decide to deprecate and eventually neutralize this flag entirely rather than just discouraging its use?