Var-args and method overloading doubt

[Sridhar Gudipalli]

Source: Exam Lab Practice test #2, Q#33

  
public class Flows {
	public static void main(String[] args) {
		//callMethod(2, 3); 
		//callMethod(new Integer(2), new Integer(3));
	}
	
	public static void callMethod(Integer... i){
		System.out.println("Wrapper");
	}
	
	public static void callMethod(int... i){
		System.out.println("Primitive");
	}
}

This program allows to overload the methods in this way. But doesnot allow to call them. I understand the reason of ambiguity. But if that is the case why the compiler allows to define these methods? In other way, how to invoke these methods? Am I missing something here? Any help please!!

[Joshua Antony]

byte b1=2;
    	byte b2=3;
        callMethod(b1,b2);   

Above code gets executed successfully

[Emanuele Ghe]

Joshua Antony wrote:

byte b1=2;
    	byte b2=3;
        callMethod(b1,b2);   

Above code gets executed successfully

I have the same doubt and I think it works because widening is preferred above boxing, so it wides the bytes to int and calls
the int one.

If you try to pass any int/integer, it does not work.

Why ?

[Sahil Kapoor]

NOTE: Compiler does not perform widening and Autoboxing (in this order). It is too much for a compiler to perform. In a Nutshell, compiler does not try to Autobox after widening.

In case of callMethod(2,3) : Bot the arguments are int , hence compiler would get confused, because both could be widened or Autoboxed.
When Widened:- Matched to callMethod(int... i)
When Autoboxed:- Matched to callMethod(Integer, Integer);

In case of callMethod((byte)2,(byte)3) : Both the arguments are byte. Compiler looks for callMethod(byte, byte). After failure it can match it for callMethod(int...i) by "Widening" bytes. Since after widening compiler never performs Autooboxing therefore this time compiler is not confused about linking the call by actual method, since this call only matches with callMethod(int...i).

Hope you understand !!!
Take care
Cheers!!!

[Sahil Kapoor]

Compiler allows to define the above methods because they can actually be called without ambiguity.

callMethod((byte)2,(byte)3); -->Calls callMehtod(int...i) without Ambiguity.

<Dont know > -->Calls callMethod(Integer,Integer).

Can anyone tell which call wuld invoke callMethod(Integer...i) without Ambiguity !!!

Thanks !!!

[suresh krishna Avanthkker]

"widening should not lose out to newly created method that relies on boxing"as quoted in book.
if argument is byte and in the parameters there is an option of

callMethod(int, int)

and

callMethod(Integer,Integer)

then callMethod(int, int) will work.

"you can box and widen(An int can become an Object , through an Integer" you cant do the reverse.
In callMethod(2, 3) since both 2 and 3 is byte, I think callMethod(int ...i) will not be called as widening
beats boxing and boxing beats var-args .AscallMethod(int ...i) is var-args ,widening will beat var-arg and there
no option of widening i.e callMethod(int, int) therefore then boxing has to take place
so byte is boxed to Byte and widened to Object and callMethod(Integer... i) will cast the Object reference
to Integer, therefore callMethod(Integer... i) has to work.