What is the difference between static (early) binding and dynamic (late) binding in Java, and when does each happen?

## What "binding" means When you write `obj.doThing()` or read `obj.value`, the compiler and JVM must figure out *which* concrete method body runs or *which* field is read. Connecting that name in your source code to a concrete member is called **binding**. Java does this in two different moments. ## Two key types in play Every reference variable has two types: - **Compile-time type (declared/static type):** the type written in the variable's declaration. In `Animal a = new Dog();` the compile-time type of `a` is `Animal`. - **Runtime type (dynamic/actual type):** the class of the object actually created on the heap — here `Dog`. Which type is used to resolve the member is exactly what distinguishes the two bindings. ## Static (early) binding **Static binding** (also called *early binding*) happens at **compile time**, using the **compile-time type** of the reference. The decision is baked into the bytecode and never changes at run time. It applies to: - **Fields** — `a.legs` reads the field declared in the compile-time type. Fields are *never* polymorphic. - **`static` methods** — resolved by the declared type; redeclaring one in a subclass is *hiding*, not overriding. - **`private` methods** — not visible to subclasses, so no override is possible. - **`final` methods** — cannot be overridden, so the target is fixed. - **Overload resolution** — *which* overloaded signature (e.g. `print(int)` vs `print(long)`) is chosen is always a compile-time decision based on the static types of the arguments. A non-virtual call in JVM terms is one the JVM does not have to look up per-object; it uses `invokestatic` or `invokespecial`. ## Dynamic (late) binding **Dynamic binding** (also called *late binding* or *virtual invocation*) happens at **run time**, using the **runtime type** of the object. It applies to ordinary, overridable instance methods. The compiler only records the method's name and descriptor (its signature); the JVM, at the moment of the call, looks up the actual object's class and invokes the most-derived override. This is implemented with the `invokevirtual` bytecode (or `invokeinterface` for interface-typed references), typically via a per-class method table (vtable) the JVM walks. This is the mechanism that makes **runtime polymorphism** work: `Animal a = new Dog(); a.sound();` prints the Dog sound even though `a` is declared as `Animal`. ## The classic gotcha: methods vs fields ```java class Animal { int legs = 4; String kind() { return "animal"; } } class Dog extends Animal { int legs = 4; String kind() { return "dog"; } } Animal a = new Dog(); a.kind(); // "dog" -> method: dynamic binding, uses runtime type Dog a.legs; // Animal's legs -> field: static binding, uses compile-time type Animal ``` Methods dispatch on the runtime type; field *access* and `static` method *invocation* resolve on the compile-time type. Mixing these up is a very common interview trap. ## Why Java made this choice Virtual dispatch for instance methods is what lets subclasses specialize behavior — the core of OOP. Static binding for fields and statics keeps them fast and predictable (no per-object lookup) and avoids surprising shadowing semantics. The cost of dynamic dispatch is a small indirection, which modern JITs largely erase via inlining and monomorphic/bimorphic call-site optimization.