Overloaded varargs param doubt

[kurt hanni]

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...

[marc weber]

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

[nico dotti]

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]

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.

   
class MethodPriority {
public static void main (String [] args) {
foo(5);//chooses the long over the Integer!
bar(5);// chooses Number as it can't unbox the int into an Integer
   // and then widen it into a Long..remember, Long and Integer are
   // both derivatives of Number. That's like trying to say that 
   // Cat IS A Dog in the Number world! Unintuitive as it is it
   // makes sense if you think about it: Number>>Integer
   //                                    Number>>Long
   //  An Integer ain't a Long!
//fubar(5);// reproduction of your compiler error...it simply
// can't tell that an int is more specific since it's 
// already covered that when it tried to see if widening
// was an option. Now that it's looking at two var arg methods
// it doesn't know which one is more specific.
}
 
static void foo(Integer i) {
System.out.println( "foo chose Integer..." );
}
static void foo(long l) {
System.out.println( "foo chose long..." );
}
static void bar(Number n) {
System.out.println( "bar chose Number...");
}
static void bar(Long l) {
System.out.println( "bar chose Long...");
}
static void fubar(Integer... iVArgs) {
System.out.println( "Integer var args chosen...");
}
static void fubar(int... intVarArgs) {
System.out.println( "int var args chosen...");
}
}
 
 

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

[marc weber]

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]

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]

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...

class VarMeths {
  static void meth(Number... num) {
    System.out.println("Number version...");
    System.out.println(num);
  }
  static void meth(Object... obj) {
    System.out.println("Object version...");
    System.out.println(obj);
  }
  public static void main(String[] args) {
    Integer[] inArr = { new Integer(1), new Integer(2) };
    meth(inArr);
  }
}

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]

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]

thanks a lot guys... your discussions makes it alot clearer

[nico dotti]

Yeah, thanks Marc that helps a lot.