• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Confusion about var...arguments!!

 
swapnil dangore
Ranch Hand
Posts: 46
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi all ,
I'm not getting the concept of var... arguments when it comes with overloaded methods. Take a look at following example.

void method(short s){
System.out.println("short argument");
}
void method(int i){
System.out.println("intargument");
}

Invoking this method as
method((short)5);
prints :- short argument

But with var.. arguments

void method(short... s){
System.out.println("short argument");
}
void method(int... i){
System.out.println("intargument");
}

It gives following compile time error
reference to method is ambiguous, both method method(short...) in test and method method(int...) in test match

What is the API Developer's thinking behind Var... arguments?
 
Barry Gaunt
Ranch Hand
Posts: 7729
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Please pay attention to my fellow bartender's request here.
[ December 15, 2006: Message edited by: Barry Gaunt ]
 
swapnil dangore
Ranch Hand
Posts: 46
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Sorry.....I did not see it....Done as per your request
 
Barry Gaunt
Ranch Hand
Posts: 7729
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks.
 
Burkhard Hassel
Ranch Hand
Posts: 1274
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi ranchers,

there has been a longer thread about this.

But be warned, at the beginning of this thread, all cowboys went to the wrong trail, as they thought it had something to do with boxing, but it hadn't.

The thread:
http://www.coderanch.com/t/260209/java-programmer-SCJP/certification/Var-args-explanation-needed


Also Swapnils question has nothing to do with boxing, but the answer is in this thread.



Yours,
Bu.
 
Barry Gaunt
Ranch Hand
Posts: 7729
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Without reading that thread I have got as far as reasoning that the compiler does not know whether to choose between int[] and short[]. That is, it must provide a single element array of one of these two types. Why it cannot choose the short[] rather than the int[] I have no idea at the moment.
 
Barry Gaunt
Ranch Hand
Posts: 7729
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Sun Java Bug Report

We are using int and short, but it's the same bug isn't it?
[ December 16, 2006: Message edited by: Barry Gaunt ]
 
Burkhard Hassel
Ranch Hand
Posts: 1274
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks, Barry, for this link!

So if it is called a bug officially, there's a chance that a question like this might not appear on the exam...


Yours,
Bu.
 
Charles Lyons
Author
Ranch Hand
Posts: 836
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
It's interesting that Sun have marked this as a bug with a fix in progress... Reading the JLS carefully (I think) shows an ambiguity compilation error is to be expected in this case.

In particular, int... becomes int[] and short... becomes short[] after compilation, and these array types aren't related (short[] is not a subtype of int[], even though the short elements can be implicitly cast to ints). As a result, a method with parameter short[] is not more specific than a method with parameter int[] (these methods would be equally specific).

So, invoking with at least one int argument leaves the compiler with only one applicable method, i.e. the one with int... parameter. But, all short arguments could be placed into either short[] or int[] without any compilation errors, and therefore it is unclear which should be conducted, hence the ambiguity error.

In short (no pun intended): you can easily put shorts into a short[] or an int[], can't you? How does the compiler know which one you intend?

The same is true for the case presented in the bug report: ints can be put into int[] or double[], so how does the compiler know which one you intend for?

This appears to be how the JLS currently reads. The only way to rectify this with the current specificity conditions would be to say that short[] must be a subtype of int[] (and int[] a subtype of double[] etc.), which has never been true since Java day 1.
 
Barry Gaunt
Ranch Hand
Posts: 7729
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks for your response Charles.
Well I would think (guess) that the compiler would take the "path of least resistance"
If it had to choose to put the short in a short[] or an int[] then it should choose short[] over int[] to avoid a widening operation. So it would make use of the primitive widening rules (short->int->long->float->double) to aid it in resolving the "ambiguity".

I notice that the bug is dated 2004 and has not been fixed yet.
[ December 16, 2006: Message edited by: Barry Gaunt ]
 
Charles Lyons
Author
Ranch Hand
Posts: 836
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I've just read the JLS (section 15.12.2.5) again... Here's my summary of the relevant bit, simplified to remove the added complications generics bring:
Summarised from the JLS:
Method A has n parameters (T1, ..., T(n-1), Tn[]) and method B has k parameters (U1, ..., U(k-1), Uk[]), where n >= k (and [] notation means a var-arg construction, not an array).

Then A is more specific than B if:

(a) for all j from 1 to k-1, Tj <: Uj
and
(b) for all j from k to n, Tj <: Uk
So the first bit (fixed arity) works as expected with normal specificity rules (under which short <: int); but this same rule also seems to apply to the remaining variable arity (var-args) part.

To me (on a second more thorough read) this actually says that method(short...) should be more specific that method(int...), hence chosen in preference where possible.

My guess is that the current RI compiler is doing its specificity check after treating the var-arg as an array, rather than before. Hence my previous explanation shows what the RI compiler is currently doing rather than should be doing. Anyone with a second compiler at hand might have different results?

Feel free to provide any further interpretations on the JLS (or move to the advanced forum!)...
 
Charles Lyons
Author
Ranch Hand
Posts: 836
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Barry Gaunt:
I notice that the bug is dated 2004 and has not been fixed yet.
It's probably low prority because no one actually writes such blatently unclear overloads outside the SCJP exam! Just like the exam seems to like to use overloads with int and Integer, who would actually write such unclear (and unnecessary) code in reality?
[ December 16, 2006: Message edited by: Charles Lyons ]
 
swapnil dangore
Ranch Hand
Posts: 46
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks all , for your reply...
I hope ,i will not see such questions on exam...
 
It is sorta covered in the JavaRanch Style Guide.
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic