🌐 What is Dynamic Linking?

In simple words:

Dynamic linking means the JVM does not resolve all method calls, field accesses, and class references at compile time — instead, it resolves them at runtime, when the class is actually loaded.

🔗 Why Dynamic Linking Matters

In languages like C/C++, linking can be static — all symbols (functions, variables, etc.) are resolved when the program is compiled or linked.
In Java, the .class files do not contain direct memory addresses to methods/fields. Instead, they contain symbolic references (class names, method names, descriptors).
The JVM resolves (links) these symbolic references to actual memory addresses only when the class is loaded and initialized.

⚙️ How JVM Handles Dynamic Linking (Step by Step)

1️⃣ Compile Time: Symbolic References

When you compile this code:

System.out.println("Hello, Dynamic Linking!");

The bytecode will look something like:

getstatic #2 // Field java/lang/System.out:Ljava/io/PrintStream;
ldc #3       // String "Hello, Dynamic Linking!"
invokevirtual #4 // Method java/io/PrintStream.println:(Ljava/lang/String;)V

At this point, the compiler does not know the actual memory address of System.out or println() — only that they are symbols (System, out, println).

2️⃣ Class Loading Phase (Dynamic Linking Happens Here)

When the JVM loads the class that calls System.out.println():

✅ It resolves “System” to the actual java.lang.System class (by checking classpath and loading the bytecode for System).

✅ It resolves “out” to the static field System.out.

✅ It resolves “println(String)” to the correct method in PrintStream.

3️⃣ Resolution and Linking

At runtime, the JVM links those symbolic references to actual memory locations in the JVM’s method area (where loaded classes and methods live).

This process of resolving symbolic names to real addresses is called linking, and because it happens at runtime, it’s called dynamic linking.

4️⃣ Performance Optimization (Optional Step)

The JIT (Just-In-Time Compiler) may optimize these lookups later, replacing the symbolic resolution process with direct calls (like an inline cache or direct jump).
But the first time each reference is accessed, the JVM does a full dynamic lookup.

📦 Example Flow Summary

Stage	What Happens
Compilation	Compiler records only symbolic references (class names, method names, descriptors)
Class Loading	JVM loads class bytecode into memory
Dynamic Linking	JVM resolves symbolic references to real memory addresses (only once per class/method/field)
Execution	Instructions like `invokevirtual` use the resolved addresses

🚀 Why Dynamic Linking is Awesome

✅ Makes Java platform-independent (no fixed addresses).
✅ Allows hot-swapping or replacing classes at runtime (great for tools like Spring and Hibernate).
✅ Supports reflection (because methods and fields can be resolved dynamically).
✅ Enables polymorphism, because the actual method implementation is resolved dynamically (based on runtime type).

⚠️ Dynamic Linking = Cost vs Flexibility

Dynamic linking is more flexible but slightly slower than static linking.
This is why the JIT Compiler (in HotSpot JVM) tries to replace it with optimized direct calls after the first resolution.

💡 Summary Chart

Language	Linking Type	When?
C/C++	Static Linking	Compile Time
Java	Dynamic Linking	Runtime (during class loading)

JVM.Internals.How does the JVM handle dynamic linking?