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 ]
Joined: Oct 09, 2007
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 ]
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).
Joined: Oct 09, 2007
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 ]
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?...
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.
...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.