At compile time, how does Java choose among overloaded methods, and why can overloading combined with overriding produce surprising results?

## Two independent decisions, made at two different times The single most important idea here: **Java makes two separate decisions about a method call.** 1. **Which overload (signature) to call** — decided by the **compiler**, using the **static (declared) types** of the arguments. 2. **Which overridden body of that signature to run** — decided by the **JVM at runtime**, using the **dynamic type** of the *receiver object*. These never mix: dynamic dispatch can only choose among overrides *of the signature the compiler already locked in*. Forgetting this produces almost every "WTF" example in this area. ## Phase 1, 2, 3: how the compiler narrows the candidates Given a call like `m(arg1, arg2)`, the compiler collects all *accessible* methods named `m` and finds the **applicable** ones in three phases, **stopping at the first phase that yields at least one**: - **Phase 1 — strict invocation:** applicable by *subtyping* and **widening primitive conversions** only. No boxing, no varargs. (`int`→`long`→`double`; `Dog`→`Animal`.) - **Phase 2 — loose invocation:** everything in phase 1 **plus autoboxing/unboxing** (`int`↔`Integer`). Still no varargs. - **Phase 3 — variable arity:** everything above **plus varargs** (`int...`). This ordering is why an `int` argument prefers `f(long)` (widening, phase 1) over `f(Integer)` (boxing, phase 2) over `f(int...)` (varargs, phase 3), even if all three exist. ## Most-specific rule and ambiguity If a phase yields multiple applicable methods, the compiler keeps the **most specific** one: method A is more specific than B if any argument set valid for A is also valid for B (loosely, A's parameter types are subtypes of B's). If neither is more specific, the call is **ambiguous** and is a **compile error** — you must cast an argument to disambiguate. ## Trap 1: static type, not runtime type, picks the overload ```java void print(Object o) { System.out.println("Object"); } void print(String s) { System.out.println("String"); } Object o = "hello"; print(o); // prints "Object" — declared type is Object print("hi");// prints "String" — declared type is String ``` Even though `o` *holds* a String at runtime, the compiler only sees `Object o`, so it binds `print(Object)`. Overloading is purely a compile-time, static-type decision. (If you genuinely want runtime-type-based selection you need the visitor pattern or `instanceof`/pattern matching, not overloading.) ## Trap 2: overloading + overriding together ```java class Base { void who(Base b) { System.out.println("Base.who(Base)"); } } class Sub extends Base { void who(Base b) { System.out.println("Sub.who(Base)"); } // OVERRIDES void who(Sub s) { System.out.println("Sub.who(Sub)"); } // OVERLOADS } Base b = new Sub(); b.who(new Sub()); ``` What prints? The compiler sees `b`'s static type `Base`, which only has `who(Base)`. So the **signature is locked to `who(Base)`**. At runtime, dynamic dispatch finds `Sub`'s override of `who(Base)`. Result: **`Sub.who(Base)`** — NOT `Sub.who(Sub)`, even though the argument is really a `Sub`. The overload was chosen statically (only `who(Base)` was visible); the override was chosen dynamically. ## Trap 3: null and ambiguity ```java void g(String s) {} void g(Integer i) {} g(null); // COMPILE ERROR: ambiguous — null fits both, neither more specific ``` `null` is assignable to every reference type. The compiler tries to pick the **most specific** reference parameter. With unrelated types (`String`, `Integer`) neither is more specific, so it is ambiguous. With related types (`Object` vs `String`), `String` wins because it is more specific. Disambiguate by casting: `g((String) null)`. ## Trap 4: widening beats boxing beats varargs (and `byte`/`short` surprises) ```java void h(long x) {} void h(Integer x) {} void h(int... x) {} h(5); // calls h(long): widening (phase 1) beats boxing (phase 2) beats varargs (phase 3) ``` ## Why this matters in practice - API designers should avoid overload sets that differ only by closely-related reference types or by primitive-vs-wrapper, because callers (and `null`) hit ambiguity or pick the "wrong" one. - Code reviewers should be suspicious when a method is *both* overloaded and overridden in a hierarchy — that is the classic source of the Trap 2 surprise. ## Deriving the answer Hold two facts and you can derive every case: **(1) overload selection is compile-time and uses declared types via the 3-phase, most-specific rule; (2) override selection is runtime and only chooses among bodies of the already-fixed signature.** Apply them in that order to any tricky example and the result falls out.