22

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?

Pshemo
  • 122,468
  • 25
  • 185
  • 269
awaelchli
  • 796
  • 7
  • 23
  • 1
    This is not an exact duplicate (of that question). The other question has a `long...` overload (variadic and widening) this has `int,int`. So, while it's *related* .. –  Aug 03 '12 at 21:35
  • http://stackoverflow.com/questions/4921589/overloading-with-both-widening-and-boxing (to get "related") –  Aug 03 '12 at 21:37
  • Now, what about if it was invoked as: `method(new Integer(1), new Integer(2))` ..? It would be interesting to see it addressed when the call goes this route. I do not know rules well enough :-/ –  Aug 03 '12 at 21:42
  • 1
    @pst unboxing comes before varargs in the hierarchy, so `method1(int, int)` would still be called. – assylias Aug 03 '12 at 21:49
  • Not a duplicate. Voted to close by mistake. – Mechanical snail Aug 06 '12 at 04:56

5 Answers5

30

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.

assylias
  • 321,522
  • 82
  • 660
  • 783
  • Ok, so it seems that there is actually more behind the basic rules in overloading methods I learned in school. So you say that the java compiler goes through all the methods and finds the most suitable according to this list you mentioned? – awaelchli Aug 03 '12 at 21:41
  • 4
    Never mind what HE says, that's what the spec he quoted says ;-) – Richard Sitze Aug 03 '12 at 21:42
4

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.

Sergey Kalinichenko
  • 714,442
  • 84
  • 1,110
  • 1,523
  • Ok thank you very much. I believe that I understand the basic idea behind this, even though I never heard about boxing and overload resolution – awaelchli Aug 03 '12 at 21:48
2

A call will made to method1(int a, int b) . Just checked byte code for this - here Integer... a is actually an Integer[] a For a detailed conversion check these assignment conversion

Jeromy French
  • 11,812
  • 19
  • 76
  • 129
exexzian
  • 7,782
  • 6
  • 41
  • 52
  • 1
    Thank you for the effort. So you compiled it into a .class and opened it to see the bytecode and you checked the difference between the two methods right? that is very clever and a good trick to find out whats going on behind that. but bytecode is a bit more complicated isnt it? – awaelchli Aug 03 '12 at 22:02
  • @aeduG yeah after thinking logically and JSL perspective I just check its .class using DJDecompiler and doing so always helps me a ton – exexzian Aug 03 '12 at 22:15
  • @aeduG yeah its complicated but DJDecompiler gives its both bytecode form as well as compiler expanded code like converting `Integer... a` to `Integer[] a` and `System.out.println(a+"hello");` to `System.out.println((new StringBuilder()).append(a).append("hello").toString());` – exexzian Aug 03 '12 at 22:21
2

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.

Kevin Welker
  • 7,719
  • 1
  • 40
  • 56
  • So, less "boxing" or (how i understand it) "converting" is better. So the compiler goes the way with least work :) he is lazy :D – awaelchli Aug 03 '12 at 21:54
  • more or less, but the other answers which cite the JLS are more specific. There is a defined order of coercion types that it follows. – Kevin Welker Aug 03 '12 at 22:18
1

varargs has the least priority. If no other matched method found then only it gets called.It is just like the default case of SWITCH case.

Thorang Katchen Ale
  • 21
  • 5