aspose file tools*
The moose likes Programmer Certification (SCJP/OCPJP) and the fly likes Overloaded varargs param doubt Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Programmer Certification (SCJP/OCPJP)
Bookmark "Overloaded varargs param doubt" Watch "Overloaded varargs param doubt" New topic
Author

Overloaded varargs param doubt

kurt hanni
Ranch Hand

Joined: Aug 11, 2007
Posts: 140

hello guys, how come this code doesnt compile if i use the method and pass a int to it, it produces a compile error

"reference to x is ambiguous, both method x(java.lang.Integer...) in Sample and method x(int...) in Sample match new Sample().x(5);"

but if i didnt use the method at line 1, the code will compile,

it looks like that both are valid overloaded methods, until you start using it the compiler cant find w/c method to use and sees them as the same.



public class Sample {
public static void main(String[] args) {
new Sample().x(5); // line 1
}

void x(Integer... i) {
System.out.println("Integer...");
}

void x(int... i) {
System.out.println("int...");
}
}

I thought the answer was "int..." ???

thanks...


SCJA, SCJP, SCJD, SCMAD, SCWCD, SCBCD, SCDJWS, SCEA, SOA, Spring Certified, OCP MySQL 5 Developer, PMP
marc weber
Sheriff

Joined: Aug 31, 2004
Posts: 11343

See SCJP FAQ: What is a most-specific method? Let us know if that clears it up.


"We're kind of on the level of crossword puzzle writers... And no one ever goes to them and gives them an award." ~Joe Strummer
sscce.org
nico dotti
Ranch Hand

Joined: Oct 09, 2007
Posts: 124
Ranchhands correct me if I'm wrong but as I remember, when looking at overloaded methods such as this, it helps to think the JVM will look
1)
for the most applicable method without using autoboxing (so if you had a method that was not a var arg method (int...)etc., that took a long: (long l), it would prefer to choose to 'widen' the int and use that overloaded method as an int can implicitly be upcast to a long. But you have two var args so it can't do that...
2)
If it can't widen, then see if it can automatically unbox...so for an int arg, if you have a method that took say (Integer i) the int arg would automatically be unboxed to an object of type Integer...but you don't have any methods like that either....
3)
It's last choice is to use var args which won't apparently give preferential treatment to the primitive widening version or the unboxed version...I'm not sure, but it seems that it's already tried to go through the steps in an orderly fashion as if saying (hmm, can I widen? no...hmm, can I unbox or box? no...oh, these are var args...well, I could work with either of these so which do I choose? Duh...I dunno! Hmm, I think I'll complain that this guys giving me two choices that would both work (ambiguous) ) So in essence, it can't go back to prioritizing widening over unboxing once it's reached step 3.

Condensed rule for figuring out which overloaded method will be used:
1) try widening
2) try autoboxing/unboxing (we also can't widen AFTER boxing so note that we can't unbox then widen)
3) try var-args (we can no longer prioritize between widening and boxing!)

This is a confusing topic that takes a lot of experimentation to grasp clearly! I think the 3 step rule above really helped me...so hopefully it works for you too.

Of course, I'd like to get confirmation of my analysis from a ranchhand :roll:

[ December 02, 2007: Message edited by: nico dotti ]
[ December 02, 2007: Message edited by: nico dotti ]
nico dotti
Ranch Hand

Joined: Oct 09, 2007
Posts: 124
So I went ahead and created a test program and reproduced your error along with showing how it work given the other steps I mentioned in my last post...firstly here's the proof of error reproduction:
MethodPriority.java:5: reference to fubar is ambiguous, both method fubar(java.lang.Integer...) in MethodPriority and method fubar(int...) in MethodPriority match
fubar(5);
^
1 error


Here's my code which you should run...first let it run with the call to fubar commented out so you can see step 1 and 2 in affect. Then uncomment the fubar call to reproduce your error.


[ December 02, 2007: Message edited by: nico dotti ]
marc weber
Sheriff

Joined: Aug 31, 2004
Posts: 11343

Originally posted by nico dotti:
...I'd like to get confirmation of my analysis from a ranchhand...

You are correct!

There are some subtle details to this, discussed under JLS - 15.12.2 ... Determine Method Signature.

Basically, there are three phases designed to "ensure compatibility with older version of the Java programming language." The first phase attempts to resolve the overload without considering boxing/unboxing or "variable arity method invocation" (which is how the JLS refers to varargs). If this does not work, then the second phase considers boxing/unboxing, but not varargs. If this does not work, then the third phase considers varargs (while also allowing boxing/unboxing).
nico dotti
Ranch Hand

Joined: Oct 09, 2007
Posts: 124
Thanks...so just to be certain, is it true that once it gets to the 3rd phase/var args, it won't be able to distinguish specificity using widening as a consideration? If so, is that because the logic just doesn't provide for 'backpeddling' back to step one and checking for widening since it's got to step 3 already? Gosh that was a mouthful, I'm beginning to sound like Richard Stallman explaining the recursive meaning of GNU LOL...btw, I love the man winkwink

Another off the subject question. I just took enthuware's thread specific test and it had like 3 thread priority question on it. I actually got them all right, but I'm concerned how it shows up on the scjp test. I use linux and it doesn't seem to use thread priority at all, so as far as I'm concerned, it's just an added 'maybe it'll help' feature. I think that's what the powers that be want you to use as a rule (that it may or may not work)...is that correct? Whew! If not, they'd be hatin' on us Linux Homies!!! LMK big Marc! Oh, and peace out from da 'burbs!
[ December 02, 2007: Message edited by: nico dotti ]
marc weber
Sheriff

Joined: Aug 31, 2004
Posts: 11343

Originally posted by nico dotti:
Thanks...so just to be certain, is it true that once it gets to the 3rd phase/var args, it won't be able to distinguish specificity using widening as a consideration?...

If varargs are being used, then we're really talking about arrays. See JLS - 4.10.3 Subtyping among Array Types. So, for example, the following works...

But trying something similar with primitives would not work. For example, an int can be widened to type long, but int[] is not a subtype of long[].
marc weber
Sheriff

Joined: Aug 31, 2004
Posts: 11343

Originally posted by nico dotti:
... Another off the subject question. I just took enthuware's thread specific test and it had like 3 thread priority question on it. I actually got them all right, but I'm concerned how it shows up on the scjp test...

Yes, this would probably be better addressed as a separate topic, but...

What you might need to know for the exam is that Java threads can have int priorities ranging from 1-10. The default is 5, although threads inherit the priority of the creating Thread. The constant MIN_PRIORITY is 1, MAX_PRIORITY is 10, and NORM_PRIORITY is 5.

However, thread scheduling -- including how thread priorities might be considered -- is platform dependent, and therefore unpredictable. So I would not expect the exam to ask you to predict output based on thread priorities.

In fact, Horstmann and Cornell warn on page 19 of Core Java 2: Volume II -- Advanced Features...
...thread priorities are highly system dependent...

For example, Windows NT/XP has seven priority levels. Some of the Java priorities will map to the same operating system level. In the Sun JVM for Linux, thread priorities are ignored altogether -- all threads have the same priority.

Thus, it is best to treat thread priorities only as hints to the scheduler. You should never structure your programs so that their correct functioning depends on priority levels.

CAUTION: ...If you have several thread with a high priority that rarely block, the lower-priority thread may never execute.

And in Thinking in Java, Eckel says...
...Windows 2000 has 7 priority levels that are not fixed, so the mapping is indeterminate (although Sun's Solaris has 2^31 levels). The only portable approach is to stick to MAX_PRIORITY, NORM_PRIORITY, and MIN_PRIORITY when you�re adjusting priority levels.
kurt hanni
Ranch Hand

Joined: Aug 11, 2007
Posts: 140

thanks a lot guys... your discussions makes it alot clearer
nico dotti
Ranch Hand

Joined: Oct 09, 2007
Posts: 124
Yeah, thanks Marc that helps a lot.
 
Don't get me started about those stupid light bulbs.
 
subject: Overloaded varargs param doubt