All 15 Class Loading & Bytecode Verification questions
More in Class Loading & Bytecode Verification
What causes a ClassNotFoundException versus a NoClassDefFoundError, and how do you distinguish and diagnose each? How does the Java Platform Module System (JPMS, introduced in Java 9) change class loading and encapsulation compared to the traditional classpath model? What is the purpose of the -Xverify:none (or newer -noverify) JVM flag, and why is disabling bytecode verification generally discouraged? How does the ServiceLoader mechanism (java.util.ServiceLoader) provide a standardized way to discover and load implementations at runtime without hardcoding class names, and how does it relate to class loading? How would you implement a custom ClassLoader to load classes from a non-standard source, such as loading plugin JARs dynamically at runtime, and what challenges arise with class unloading? What is bytecode verification, and what specific categories of invalid or unsafe bytecode does the JVM's verifier reject before allowing a class to run? How does the same class name loaded by two different ClassLoaders create two genuinely distinct types in the JVM, and what problems does this cause (such as with singletons or ClassCastException)? How would you diagnose and resolve a 'split package' problem when using JPMS, where the same package is defined across two different modules on the module path? How does Class Data Sharing (CDS) and Application Class Data Sharing (AppCDS) improve JVM startup time, and how does it relate to class loading and verification? How does a thread context ClassLoader (Thread.currentThread().getContextClassLoader()) solve the problem of a core JDK class needing to load an application-provided implementation class, given parent delegation normally prevents this?
Advertisement
Java › Class Loading & Bytecode Verification

What is hot class reloading/redefinition (via Instrumentation.redefineClasses() or a JVM agent), and what are its practical limitations compared to a full class unload/reload?

Intermediate

Answer

Class redefinition (used by tools like JRebel, or IDE-driven "hot swap" during debugging) allows an already-loaded class's bytecode to be replaced with a new version at runtime without restarting the JVM or creating a genuinely new ClassLoader -- however, the JVM's standard redefinition mechanism has significant limitations: it generally cannot add or remove methods/fields, or change a class's superclass/interfaces (only method body implementations can typically be swapped), which is why commercial hot-reload tools like JRebel implement considerably more sophisticated (and more permissive) reloading using deeper bytecode manipulation and instrumentation techniques beyond the JVM's basic built-in redefinition API.
// Simplified illustration using the Instrumentation API (typically invoked via a Java agent)
public class HotSwapAgent {
    public static void premain(String args, Instrumentation inst) {
        // inst.redefineClasses() can later replace a loaded class's bytecode,
        // but only method bodies -- not its structure (fields, method signatures)
    }
}
Real-world example A developer debugging in an IDE modifies a method's implementation and uses the IDE's hot-swap debugging feature to apply the change without restarting the application, relying on exactly this same JVM class redefinition mechanism, but discovers that adding a brand new method to the class requires a full restart since basic redefinition can't handle structural changes.

Common follow-ups: Why can't the basic JVM redefinition mechanism add or remove fields/methods, while a full JVM restart obviously can?;How do tools like JRebel achieve more flexible hot-reloading beyond the JVM's built-in limitations?

Diagnostics & Performance;Testing Strategy
All 15 Class Loading & Bytecode Verification questions