Which method is called? (Integer... a) vs. (int a, int b)

Question

I just found out about a very interesting Java trick:

void method1(Integer... a){
}

So you can give this method as many integers as you want.

Now if I have a similar (overloaded) method like this:

void method1(int a, int b){

}

Which method runs when I execute the following line:

method1(1, 2);

Well, I could find that out very easily by just testing it out with different method instructions but when I think about the "rules" in "overloading" methods then I have to make sure that every overloaded method must be identical so that the compiler knows exactly which one to use.

In my opinion, the code above shouldn't work because the compiler should be confused. But when I try it out it works.

So.. does anyone know a bit more background information about this?

Answer 1

To determine which method should be called, the compiler goes through the following list, as detailed in the JLS #5.3 and JLS #15.12.2:

• an identity conversion (§5.1.1) => method1(int a, int b)
• a widening primitive conversion (§5.1.2)
• a widening reference conversion (§5.1.5)
• a boxing conversion (§5.1.7) optionally followed by widening reference conversion ==> method1(Integer... a)
• an unboxing conversion (§5.1.8) optionally followed by a widening primitive conversion.

In your case, the first point applies and method1(int, int) is called.

(To be more precise, your method uses varags and has a lower priority than a simple boxing conversion. In other words, if there were a method1(Integer a, Integer b) it would come before method1(Integer... a) in the hierarchy)

Why is it so? A comment in 15.12.2 give a hint:

This guarantees that any calls that were valid in the Java programming language before Java SE 5.0 are not considered ambiguous as the result of the introduction of variable arity methods, implicit boxing and/or unboxing.

Answer 2

The second method wins. According to the Java Language Specification (pdf),

The first phase (§15.12.2.2) performs overload resolution without permitting boxing or unboxing conversion, or the use of variable arity method invocation.

If an applicable method is found during this stage, that method wins; no further search is performed. In your case, it happens to be the second method, because the first one is a variable arity method that also requires boxing.

Answer 3

I'm half guessing, but like thinksteep said, Integer... is actually treated as an Integer array, which implies that your method call would have to do two coercions to make it match the first method (boxing the ints to Integers, and treating your argument list as an array rather than simply two different arguments). Whereas, no coercions are required to make it match the second method.

OK, I can see several others have already quoted the JLS with more specificity than I have provided, while I was typing this out.