Finding the most specific method is defined in a very formal way in the Java Language Specificaion (JLS). I have extracted below the main items that apply while trying to remove the formal formulae as much as possible.
In summary the main items that apply to your questions are:
- JLS 15.12.2: your use case falls under phase 3:
The third phase (§15.12.2.4) allows overloading to be combined with variable arity methods, boxing, and unboxing.
- Then JLS 15.12.2.4 basically determines that both method are applicable, because 10 can be converted to both an
Integer...
or anint...
. So far so good. And the paragraph concludes:
The most specific method (§15.12.2.5) is chosen among the applicable variable-arity methods.
- Which brings us to JLS 15.12.2.5. This paragraph gives the conditions under which an arity method
m(a...)
is more specific than another arity methodm(b...)
. In your use case with one parameter and no generics, it boils down to:
m(a...)
is more specific thanm(b...)
iifa <: b
, where<:
meansis a subtype of
.
It happens that int
is not a subtype of Integer
and Integer
is not a subtype of int
.
To use the JLS language, both call
methods are therefore maximally specific (no method is more specific than the other). In this case, the same paragraph concludes:
- If all the maximally specific methods have override-equivalent (§8.4.2) signatures […] => not your case as no generics are involved and Integer and int are different parameters
- Otherwise, we say that the method invocation is ambiguous, and a compile-time error occurs.
NOTE
If you replaced Integer...
by long...
for example, you would have int <: long
and the most specific method would be call(int...)
*.
Similarly, if you replaced int...
by Number...
, the call(Integer...)
method would be the most specific.
*There was actually a bug in JDKs prior to Java 7 that would show an ambiguous call in that situation.