Win a copy of Re-engineering Legacy Software this week in the Refactoring forum
or Docker in Action in the Cloud/Virtualization forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Overloading Ambiguously

 
Gowher Naik
Ranch Hand
Posts: 643
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator


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
Posts: 15
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Let me know u r using jdk1.4 or 1.5?
 
Barry Gaunt
Ranch Hand
Posts: 7729
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 7729
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 2023
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 196
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 7729
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 7729
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 107
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 7729
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 107
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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 ]
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic