Overloading Ambiguously

[Gowher Naik]

class Test{
public static void main(String args[]){
method(1);
method(new Integer("1"));
}
static void method(Integer... i){
System.out.println("Integer");
}
static void method(int... i){
System.out.println("int");
}
}

when i compile above code it gives error as follows
"reference to method is ambiguous, both method method(java.lang.Integer...) in Test and method method(int...) in Test match"

I am not able to understand why

Thanks

[nirumagics]

Let me know u r using jdk1.4 or 1.5?

[Barry Gaunt]

Hello "nirumagics"-

Welcome to JavaRanch.

On your way in you may have missed that we have a JavaRanch Naming Policy for displayed (screen) names. Your displayed name must consist of a first name (or an initial), a space, and a family name (in that order) and not be obviously fictitious. Since yours, "nirumagics", does not conform with it, please take a moment to change it, which you can do right here.

Posters with nonconforming displayed names will be locked out of JavaRanch after a few posts using those names.

Thanks
-Barry

(NR) - search tag (more than once)

[Chandrashekhar B Manda]

I think this is the case of 1.5 remember (int ... i)
but make sure that you are passing an array when it is required instead of one element.

[Barry Gaunt]

It is clear that this is a Java 5.0 example because of the var-args parameters int... and Integer...

The compiler would be able to choose a method if one of the methods had int[] as a parameter. In that case it would choose the method with Integer... because it autoboxes the argument into a single element Integer array.

But with int... ? The compiler does not know whether to autobox the argument into a single element Integer array, or to create a single element int array.

Anybody?

[wise owen]

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4856541

At compile time a vararg is converted to an array. The varargs facility is just implicit syntax for creating and passing arrays, an array can be passed directly.

In the above code, the compiler can not decide which method is a most-specific method (The Integer[] can not convert to int[] and int[] can not convert to Integer[]).
[ July 26, 2006: Message edited by: wise owen ]

[Martin Simons]

I don't think it has anything at all to do with varargs. I think it has to do with autoboxing which makes Integer and int essentially the same thing, which makes those two methods indistinguishable.

[Barry Gaunt]

I would have chosen to put the 1 into a single element int array. So the method gets presented with the equivalent of "int [] i = {1}". That to me, seems more efficient than the equvalent of "Integer[] i = {new Integer(1)}". So a choice could be made on that basis.

But that would conflict with the choice of Integer... over an explicit int[] (because an int is not an int[]).

Maybe that's why it's ambiguous.

[Barry Gaunt]

Originally posted by Martin Simons:
I don't think it has anything at all to do with varargs. I think it has to do with autoboxing which makes Integer and int essentially the same thing, which makes those two methods indistinguishable.

If it was just autoboxing the compiler would just choose int over Integer because the argument, 1, is an int literal.

[Neelesh Bodas]

According to Choosing the most specific method rule, when more than one overloaded methods are applicable, the compiler will choose the most specific method. In the current case, neither of the two methods is "more specifc" than other. Hence the compiler will throw an ambiguity error.

[Barry Gaunt]

Originally posted by Neelesh Bodas:
According to Choosing the most specific method rule, when more than one overloaded methods are applicable, the compiler will choose the most specific method. In the current case, neither of the two methods is "more specifc" than other. Hence the compiler will throw an ambiguity error.

Why, then, does the compiler, when given an argument of 1, have no problem choosing between int[] and Integer... ? It chooses the method
with the var-args - Integer...

[Neelesh Bodas]

Originally posted by Barry Gaunt:
Why, then, does the compiler, when given an argument of 1, have no problem choosing between int[] and Integer... ? It chooses the method with the var-args - Integer...

Here is my guess (and I am not sure about it). Quoting from JLS,

Let m be a name and suppose that there are two declarations of methods named m, each having n parameters. Suppose that one declaration appears within a class or interface T and that the types of the parameters are T1, . . . , Tn; suppose moreover that the other declaration appears within a class or interface U and that the types of the parameters are U1, . . . , Un. Then the method m declared in T is more specific than the method m declared in U if and only if both of the following are true:


T can be converted to U by method invocation conversion.
Tj can be converted to Uj by method invocation conversion, for all j from 1 to n.

In the current case, int[] cannot be converted into "Integer...", but "Integer..." can be converted into int[] (In fact, a variable-length argument is always converted into an array of appropriate type.)

This is just a guess since the "method invocation conversions" in JLS donot talk anything about Boxing and var-args (or probably I couldn't find)
[ July 27, 2006: Message edited by: Neelesh Bodas ]