• 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

Ambiguous / Un-ambiguous calls involving var-args

 
Greenhorn
Posts: 23
Eclipse IDE Opera Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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 ?


 
Marshal
Posts: 79177
377
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 23
Eclipse IDE Opera Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Marshal
Posts: 79177
377
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 23
Eclipse IDE Opera Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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 !!
 
Bartender
Posts: 10780
71
Hibernate Eclipse IDE Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
 
Mandy Singh
Greenhorn
Posts: 23
Eclipse IDE Opera Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 23
Eclipse IDE Opera Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Marshal
Posts: 79177
377
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Don’t know any more. Sorry. Have you tried casting a byte[] to a long[]? Does that compile at all?
 
Bartender
Posts: 3323
86
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Marshal
Posts: 79177
377
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
If it compiles with method bodies, maybe I was right after all.
 
Mandy Singh
Greenhorn
Posts: 23
Eclipse IDE Opera Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Marshal
Posts: 79177
377
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Illegal start of type might mean you have too many { or that you have misspelt the modifiers.
 
Tony Docherty
Bartender
Posts: 3323
86
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 23
Eclipse IDE Opera Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 3323
86
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.
 
Consider Paul's rocket mass heater.
reply
    Bookmark Topic Watch Topic
  • New Topic