How does numeric promotion interact with method overload resolution and autoboxing when the compiler chooses which overloaded method to call?

## The problem overloading must solve **Overloading** means several methods share a name but differ in parameter types: `f(int)`, `f(long)`, `f(Integer)`, `f(Object)`, `f(int...)`. When you call `f(x)`, the compiler must pick exactly one at compile time. Numeric promotion's widening conversions are one of the tools it uses, but they're applied within a strict, staged algorithm so that adding autoboxing and varargs in Java 5 didn't change the meaning of existing code. ## The three phases (JLS 15.12.2) The compiler tries to find an applicable method in three successive phases; it only moves to the next phase if the current one finds nothing: 1. **Phase 1 — strict invocation**: applicability by *subtyping* and *primitive widening only*. No boxing, no unboxing, no varargs. The widening primitive conversions here are exactly the numeric-promotion ladder (`byte`->`short`->`int`->`long`->`float`->`double`, and `char`->`int`->...). 2. **Phase 2 — loose invocation**: like phase 1 but autoboxing and unboxing are now allowed. Still no varargs. 3. **Phase 3 — variable arity**: varargs (`int...`) are now considered. Within a phase, if multiple methods apply, the **most specific** one wins (roughly, the one whose parameter type can be passed to all the others). If none is strictly most specific, it's an ambiguity compile error. ## Worked consequences **Widening beats boxing.** Given `f(int)` and `f(Integer)` and a call `f(myShort)`: - Phase 1: `short` widens to `int`, so `f(int)` applies. `f(Integer)` needs boxing, not allowed in phase 1. -> `f(int)` is chosen. **More specific widening wins.** Given `f(int)` and `f(long)` and a call `f(myByte)`: - Phase 1: byte widens to both int and long, but `int` is more specific than `long`. -> `f(int)`. **Exact match wins.** `f(int)` and `f(long)` with an `int` argument -> `f(int)` (no conversion needed). **No widening between wrapper types.** Given `f(Long)` and a call `f(myInteger)`: - Phase 1 fails (`Integer` is not a subtype of `Long`). - Phase 2: unboxing `Integer`->`int` then widening `int`->`Long`? **Not allowed** — the rules permit unbox-then-widen-then-box? No. An `Integer` cannot become a `Long`; you'd get a compile error if `f(Long)` were the only option. Reference widening only follows the class hierarchy, and primitive widening only happens after unboxing to the *matching* primitive. This trips people up: `Integer` -> `long` (primitive) is allowed (unbox then widen), but `Integer` -> `Long` (wrapper) is not. **Boxing beats varargs.** `f(Integer)` and `f(int...)` with an `int` argument -> phase 2 finds `f(Integer)` before phase 3 even considers varargs. ## The famous Integer caching aside A related (but separate) gotcha: autoboxing uses `Integer.valueOf`, which caches -128..127, so `Integer a = 100, b = 100; a == b` is true but at 200 it's false. That's identity, not promotion, but it often appears in the same interview. ## A complete example ```java static void g(long x) { System.out.println("long"); } static void g(Integer x) { System.out.println("Integer"); } static void g(Object x) { System.out.println("Object"); } int i = 5; g(i); // prints "long": phase 1 widens int->long; Integer/Object need boxing (phase 2) ``` ## Deriving the answer To predict the chosen overload: (1) try strict (subtyping + primitive widening) and pick the most specific; (2) only if nothing applies, allow boxing/unboxing; (3) only then, varargs. Remember widening across *wrapper* types does not exist.