aspose file tools*
The moose likes Java in General and the fly likes Ambiguous / Un-ambiguous calls involving var-args Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of EJB 3 in Action this week in the EJB and other Java EE Technologies forum!
JavaRanch » Java Forums » Java » Java in General
Bookmark "Ambiguous / Un-ambiguous calls involving var-args" Watch "Ambiguous / Un-ambiguous calls involving var-args" New topic
Author

Ambiguous / Un-ambiguous calls involving var-args

Mandy Singh
Greenhorn

Joined: May 30, 2011
Posts: 23

Hi all,

I have 2 overloaded methods, both using var-args.

I understand that the following does not compile because of an ambiguous invocation ...



But what about the following code. Why is the method call not ambiguous ?



*** If opportunity doesn't knock, build a door !! ***
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 36478
    
  16
It is to do with the complicated rules about disambiguating overloaded method calls. That is a disincentive for overloading, so you should not overload method left right and centre. There are about 7 hits if you open the Java Language Specification and use ctrl-F-“overload”. Maybe this one will help. Or this one.

If you have a byte... it might be boxed into a Byte... which is a subtype of Number... (at least I think that is what is happening).
If you pass a Foo... that is an Object... unlesss Foo is a subtype of Number, in which case Number... is a more specific fit so Number... is chosen.
Mandy Singh
Greenhorn

Joined: May 30, 2011
Posts: 23

There are about 7 hits if you open the Java Language Specification and use ctrl-F-“overload”
I hope that wasn't a taunt

Thanks for your reply, though.

Number is chosen because its the most specific in this case but then why does the same not happen when the parameters in both the methods are primitives. for eg:



These parameters make the method call ambiguous again even though the one with 'byte... x' is more specific.
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 36478
    
  16
What on earth makes you think that was a taunt?
Passing a long[] to a byte[] is impossible, so that sorts out the ambiguity; bytes being smaller than longs are more specific, but only a byte can fit into a byte[], so the ambiguity can be sorted out.
Mandy Singh
Greenhorn

Joined: May 30, 2011
Posts: 23

Right. I somehow overlooked the fact that the var-args would be translated into an array. Thanks !

As for the misconception... well..
use ctrl-F-“overload”
I read it in a way which made me feel you were suggesting that I could just look up the answer in the JLS instead of asking. My Bad !

Anyway, good that we talked about it

Thanks a lot, mate. Cheers !!
Winston Gutkowski
Bartender

Joined: Mar 17, 2011
Posts: 7032
    
  16

Mandy Singh wrote:Right. I somehow overlooked the fact that the var-args would be translated into an array.

Unless they're already an array.

I read it in a way which made me feel you were suggesting that I could just look up the answer in the JLS instead of asking...

Which I suspect was exactly what he meant; but it wasn't a criticism. The fact is that for stuff like this, the JLS is always the place to go if you want a definitive answer; any that you get here will be an interpretation or an opinion. Now, most of the guys (and gals) here are good, but we do make mistakes from time to time...

Winston

Isn't it funny how there's always time and money enough to do it WRONG?
Artlicles by Winston can be found here
Mandy Singh
Greenhorn

Joined: May 30, 2011
Posts: 23

Ohh... I clicked on "resolved" pretty soon it seems...

In fact, that's exactly what my question was... that ambiguity can be sorted out since byte is more specific than long but the compiler says the calls are ambiguous.





These parameters make the method call ambiguous again even though the one with 'byte... x' is more specific.


We agreed that 'Number' was more specific than 'Object', hence there was no ambiguity.
Similarly, we agree that 'byte' is more specific than 'long' so there should be no ambiguity...

Campbell Ritchie wrote:bytes being smaller than longs are more specific, but only a byte can fit into a byte[], so the ambiguity can be sorted out.


So that's what... if the ambiguity can be sorted out (in case of 'byte...' and 'long...' ), why does the compiler give an error ?

I think I need to spend some time away from my computer.
Mandy Singh
Greenhorn

Joined: May 30, 2011
Posts: 23

Winston Gutkowski wrote: Now, most of the guys (and gals) here are good, but we do make mistakes from time to time...

Winston


No worries
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 36478
    
  16
Don’t know any more. Sorry. Have you tried casting a byte[] to a long[]? Does that compile at all?
Tony Docherty
Bartender

Joined: Aug 07, 2007
Posts: 1939
    
  28
That won't compile because there is no method body and you can't have abstract static methods.

When I added empty method bodies it compiled on my system - what version of Java are you using and can you show the whole compiler error message.
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 36478
    
  16
If it compiles with method bodies, maybe I was right after all.
Mandy Singh
Greenhorn

Joined: May 30, 2011
Posts: 23

Hi, sorry for the semicolons at the end of the methods I wrote above. They were not abstract methods. I just placed the semicolon by mistake while reproducing the code here.

Tony Docherty wrote: When I added empty method bodies it compiled on my system - what version of Java are you using and can you show the whole compiler error message.


Sure... the code that I am trying to compile is...


The compiler error that I get is...
D:\java_practice>javac Test.java
Test.java:13: reference to go is ambiguous, both method go(byte...) in Test and
method go(long...) in Test match
go(b);
^
1 error

I am using Java 6

Campbell Ritchie wrote:Don’t know any more. Sorry. Have you tried casting a byte[] to a long[]? Does that compile at all?

I tried doing that, but it didn't compile. It says... "Illegal start of type".
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 36478
    
  16
Illegal start of type might mean you have too many { or that you have misspelt the modifiers.
Tony Docherty
Bartender

Joined: Aug 07, 2007
Posts: 1939
    
  28
Sure... the code that I am trying to compile is...

If you put the value(s) you want to pass into a byte[] it will work.
The reason passing a byte value doesn't work (whereas passing a long does work) was explained by Campbell earlier.
Mandy Singh
Greenhorn

Joined: May 30, 2011
Posts: 23


Well, if I put the values I want to pass into a byte[], it works. But its working because a long[] cannot refer to a byte[]. So the ambiguity is resolved.

But that is not the question. My question is, why passing a 'byte' causes ambiguity (even when byte is more specific than long) ?

Tony Docherty wrote:The reason passing a byte value doesn't work (whereas passing a long does work) was explained by Campbell earlier.


Not sure which post by Campbell you are referring to. In fact in this post...

Campbell Ritchie wrote:Passing a long[] to a byte[] is impossible, so that sorts out the ambiguity; bytes being smaller than longs are more specific, but only a byte can fit into a byte[], so the ambiguity can be sorted out.
...it is said that bytes being smaller than long are more specific so the ambiguity can be sorted out.

But the fact is that the ambiguity doesn't get sorted out !

I know this is going on and on. Thanks for bearing with me.
Tony Docherty
Bartender

Joined: Aug 07, 2007
Posts: 1939
    
  28
But that is not the question. My question is, why passing a 'byte' causes ambiguity (even when byte is more specific than long) ?

Ok, I see what you mean now. The honest answer is I'm not sure without studying the JLS but I guess it's because the byte value parameter(s) have to be packaged into an array and the array type is ambiguous ie you can put bytes in a byte[] or a long[].

If you pass an int or long parameter it compiles because the only array it can use is a long[], also if you pass a byte and an int it compiles for the same reason. If you add another overloaded method which accepts a Number then you can no longer compile passing an int or long, again probably because there are multiple array types that can be used.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Ambiguous / Un-ambiguous calls involving var-args
 
Similar Threads
Overloading When Combining Widening and Boxing
Method matching.
Overloading with varargs
VarArgs
Using Final Keyword & Casting