• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Method overloading ambuiguity question.

 
Greenhorn
Posts: 12
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,

I am trying to clear my concepts on ambiguity issues when the compiler tries to resolve an overloaded method and I have a question. Look at the code below, now if I have a method that passes null as an argument i.e m1(null); I would expect that the compiler will complain that it cannot resolve which method to call. But it went through without an issue and called method m1(String o). Any ideas why this happened?


 
Ranch Hand
Posts: 92
Eclipse IDE Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi ani pillai,

You've got two methods with two different signatures so the compiler is happy with your declarations.
When you call m1 with null the compiler sees that you've given it (some kind of) object and that there are two methods which match but that's ok too.

Now when you execute your program, the null gets WIDENED to String as it is lower down the tree than Object. So your method with the String parameter is called.

I hope this helps.
 
Greenhorn
Posts: 29
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
John is right, you can demonstrate this by adding just one more method with another different paramter. Once you do this, your class will not compile because the call is indeed ambiguous.

Uncomment the third method to test:



It works the same for varargs and autoboxing, the compiler will compile this just fine:



but as soon as you try to call one of these methods like so:



it fails to compile because it's ambiguous.

HTH.
 
ani pillai
Greenhorn
Posts: 12
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Got it. The explanation was perfect.

Thank you!

 
Ranch Hand
Posts: 317
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Brian Spindler wrote:
...

but as soon as you try to call one of these methods like so:

it fails to compile because it's ambiguous.
HTH.



Hi,
now i don't understand that. For m(1) to match void m(Integer... i) {} it needs to autobox it.
But for the other method void m(int... i) {} it doesn't need it. So this is the wrong way to look at it ?!
So, because the autoboxing is done automatically it is ambiguous? No, if var-args is not used all is fine.
So the reason is the var-args. But why? Can anybody explain.
Thanks for any help
Bob
 
Ranch Hand
Posts: 71
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
When you call m1



Both methods argument can hold 'null'

but compiler chooses most precise if all of them are in same hirerchy

that is m1(String o)

because String extends Object.

But...... If you have a class MangoShake


 
Bob Wheeler
Ranch Hand
Posts: 317
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Bob Wheeler wrote:

Hi,
now i don't understand that. For m(1) to match void m(Integer... i) {} it needs to autobox it.
But for the other method void m(int... i) {} it doesn't need it. So this is the wrong way to look at it ?!
So, because the autoboxing is done automatically it is ambiguous? No, if var-args is not used all is fine.
So the reason is the var-args. But why? Can anybody explain.
Thanks for any help
Bob



To answer my question with the help of the last post

because null can be assigned to both methods arguments
but String and MangoShake are not in same hierarchy.


Because Integer... and int... is not in the same hierarchy (because of var-args???), a method call with an int parameter won't compile.
Am i right?

cheers
Bob
 
Greenhorn
Posts: 27
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Yeah... perplexing...

If having:
void go(Integer i){}
void go(int i){}

and calling:
go(1);

Works, then how come it does not with var-args?
 
John McParland
Ranch Hand
Posts: 92
Eclipse IDE Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
It doesn't work with var-args because var-args is a short-hand way of saying int[] (or some other array).

An array is a subclass of Object so you can't combine boxing and var-args too simply;

WIDENING beats BOXING
BOXING beats VAR-ARGS

Are rules to remember. But there is no rule to say whether boxing should take place or not when deciding which var-args method to use.
 
Bob Wheeler
Ranch Hand
Posts: 317
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

John McParland wrote:It doesn't work with var-args because var-args is a short-hand way of saying int[] (or some other array).

An array is a subclass of Object so you can't combine boxing and var-args too simply;

WIDENING beats BOXING
BOXING beats VAR-ARGS

Are rules to remember. But there is no rule to say whether boxing should take place or not when deciding which var-args method to use.



So, not in the same hierarchy tree.
Thanks John.
Bob
 
Ranch Hand
Posts: 1032
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
You can combine boxing and varargs. The problem is that if you end up with at least a matching method where you need to use the varargs mechanism to make the call match, then the call will be ambiguous.
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic