How do varargs participate in overload resolution? Describe the phases the compiler uses to pick a method.

## Why this matters When you call an overloaded method, the compiler must pick exactly one target at compile time. Varargs complicates this because a varargs method can match almost any argument count. To keep behavior predictable, the Java Language Specification (JLS §15.12.2) resolves overloads in **three ordered phases**, and **varargs is deliberately the last resort**. ## The three phases The compiler considers methods in this order and stops at the first phase that yields one or more *applicable* methods: 1. **Phase 1 — Strict invocation.** Match using subtyping only: **no autoboxing/unboxing, no varargs.** Each argument must be assignable to the corresponding parameter via widening reference/primitive conversion. 2. **Phase 2 — Loose invocation.** Same as phase 1 but now **autoboxing and unboxing are allowed** (e.g. `int` → `Integer`). Still **no varargs.** 3. **Phase 3 — Variable-arity invocation.** Now **varargs methods become applicable**: the trailing loose arguments are gathered into the array. If phase 1 produces any applicable method, the compiler chooses among *only* those — it never even looks at varargs. Within the chosen phase, if several methods apply, the compiler then picks the **most specific** one (the one whose parameter types are subtypes of the others'). If no single most-specific method exists, you get an **ambiguous method call** compile error. ## The headline rule: fixed-arity beats varargs Because varargs only enters in phase 3, **any applicable fixed-arity overload wins over a varargs overload.** Example: ```java void p(int a, int b) { System.out.println("fixed"); } void p(int... a) { System.out.println("varargs"); } p(1, 2); // prints "fixed" — phase-1 fixed match wins p(1); // prints "varargs" — no fixed 1-arg overload, falls to phase 3 p(); // prints "varargs" — empty array ``` This is why people say varargs has the **lowest priority** in resolution. ## Boxing also outranks varargs Phase 2 (boxing) runs *before* phase 3 (varargs). So given: ```java void m(Integer x) { ... } // fixed, needs boxing void m(int... x) { ... } // varargs m(5); // calls m(Integer) — boxing (phase 2) beats varargs (phase 3) ``` ## Ambiguity between two varargs methods If two varargs methods are both applicable in phase 3 and neither is more specific, the call is ambiguous: ```java void q(Object... o) { ... } void q(String... s) { ... } q(); // ambiguous — both apply, neither more specific (compile error) ``` (`q("a")` is *not* ambiguous: `String...` is more specific than `Object...`.) ## The 'silent steal' pitfall Because a fixed overload always wins, **adding a fixed-arity overload later can silently redirect existing calls** away from a varargs method, changing behavior without any call-site change. This is a real maintenance hazard — overload sets mixing fixed and varargs methods should be designed carefully. ## The null / array ambiguity A related gotcha: `m(null)` to `m(Object...)` is ambiguous about whether `null` is the whole array or one element; the compiler treats `null` as the array reference (with a warning). Cast explicitly — `m((Object) null)` vs `m((Object[]) null)` — to disambiguate. ## Summary Three phases: strict → loose (boxing) → varargs. Earliest applicable phase wins; within it, the most specific method wins or it's ambiguous. Varargs is last, so fixed-arity and even boxing-required overloads beat it.