wood burning stoves 2.0*
The moose likes Programmer Certification (SCJP/OCPJP) and the fly likes Overloading Ambiguously Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Programmer Certification (SCJP/OCPJP)
Bookmark "Overloading Ambiguously" Watch "Overloading Ambiguously" New topic
Author

Overloading Ambiguously

Gowher Naik
Ranch Hand

Joined: Feb 07, 2005
Posts: 643


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
Greenhorn

Joined: Jul 21, 2006
Posts: 15
Let me know u r using jdk1.4 or 1.5?
Barry Gaunt
Ranch Hand

Joined: Aug 03, 2002
Posts: 7729
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)


Ask a Meaningful Question and HowToAskQuestionsOnJavaRanch
Getting someone to think and try something out is much more useful than just telling them the answer.
Chandrashekhar B Manda
Greenhorn

Joined: May 04, 2006
Posts: 5
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.


SCJP 1.4(Cleared)<br />SCWCD X.XX Aspirant
Barry Gaunt
Ranch Hand

Joined: Aug 03, 2002
Posts: 7729
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
Ranch Hand

Joined: Feb 02, 2006
Posts: 2023
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
Ranch Hand

Joined: Mar 02, 2006
Posts: 196
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
Ranch Hand

Joined: Aug 03, 2002
Posts: 7729
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
Ranch Hand

Joined: Aug 03, 2002
Posts: 7729
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
Ranch Hand

Joined: Jul 20, 2006
Posts: 107
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
Ranch Hand

Joined: Aug 03, 2002
Posts: 7729
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
Ranch Hand

Joined: Jul 20, 2006
Posts: 107
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 ]
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Overloading Ambiguously
 
Similar Threads
overloading
re: ambiguous method calls
BETA: Method resolving, un/boxing varargs mock question
Var args question...
var...args