wood burning stoves 2.0*
The moose likes Programmer Certification (SCJP/OCPJP) and the fly likes Confusion about var...arguments!! Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of The Java EE 7 Tutorial Volume 1 or Volume 2 this week in the Java EE forum
or jQuery UI in Action in the JavaScript forum!
JavaRanch » Java Forums » Certification » Programmer Certification (SCJP/OCPJP)
Bookmark "Confusion about var...arguments!!" Watch "Confusion about var...arguments!!" New topic
Author

Confusion about var...arguments!!

swapnil dangore
Ranch Hand

Joined: Jun 05, 2006
Posts: 46
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?


Cheers<br />-------------<br />Swapnil<br /> <br />SCJP5-81%<br /> <br />"Dictionary is the only place where Success come before Work"
Barry Gaunt
Ranch Hand

Joined: Aug 03, 2002
Posts: 7729
Please pay attention to my fellow bartender's request here.
[ December 15, 2006: Message edited by: Barry Gaunt ]

Ask a Meaningful Question and HowToAskQuestionsOnJavaRanch
Getting someone to think and try something out is much more useful than just telling them the answer.
swapnil dangore
Ranch Hand

Joined: Jun 05, 2006
Posts: 46
Sorry.....I did not see it....Done as per your request
Barry Gaunt
Ranch Hand

Joined: Aug 03, 2002
Posts: 7729
Thanks.
Burkhard Hassel
Ranch Hand

Joined: Aug 25, 2006
Posts: 1274
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.


all events occur in real time
Barry Gaunt
Ranch Hand

Joined: Aug 03, 2002
Posts: 7729
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

Joined: Aug 03, 2002
Posts: 7729
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

Joined: Aug 25, 2006
Posts: 1274
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

Joined: Mar 27, 2003
Posts: 836
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.


Charles Lyons (SCJP 1.4, April 2003; SCJP 5, Dec 2006; SCWCD 1.4b, April 2004)
Author of OCEJWCD Study Companion for Oracle Exam 1Z0-899 (ISBN 0955160340 / Amazon Amazon UK )
Barry Gaunt
Ranch Hand

Joined: Aug 03, 2002
Posts: 7729
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

Joined: Mar 27, 2003
Posts: 836
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

Joined: Mar 27, 2003
Posts: 836
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

Joined: Jun 05, 2006
Posts: 46
Thanks all , for your reply...
I hope ,i will not see such questions on exam...
 
Don't get me started about those stupid light bulbs.
 
subject: Confusion about var...arguments!!