Overloading of wrapper vs primitive arguments( with and without varargs)

[Don Redd]

Hi

i am little confused with below pieces of code.

case1:
the code below is working fine!

public void method(Integer i){System.out.println("Boxed");}
public void method(int i){System.out.println("Primitive");}

//upon invocation of below statement
method(2);//output is : Primitive ; which is understandable

case2:
but,why is below code giving compile time error saying ambiguous call as both methods match invocation

public void method(Integer... i){System.out.println("Boxed");}
public void method(int... i){System.out.println("Primitive");}

//upon invocation of below statement
method(2);//output is : compile time error, ambiguous invocation.

Can someone explain whats going on in case 2,

Thanks,
Don,Redd...

[Seetharaman Venkatasamy]

Don Redd wrote:
the code below is working fine!

public void method(Integer i){System.out.println("Boxed");}
public void method(int i){System.out.println("Primitive");}

//upon invocation of below statement
method(2);//output is : Primitive ; which is understandable

when you say method(2); compiler directly map to int parameter. because one is primitive another is object. so it is obvious to understand.

Don Redd wrote:
case2:
but,why is below code giving compile time error saying ambiguous call as both methods match invocation

public void method(Integer... i){System.out.println("Boxed");}
public void method(int... i){System.out.println("Primitive");}

//upon invocation of below statement
method(2);//output is : compile time error, ambiguous invocation.

Here when you say method(2); compiler have to map either *object* []int or []Integer.
it it get confused since Integer is wrapper improvement of an int . if you want to map []int call then,
you can always cast to less type of int like method((char)2) etc.. coming to the point yes
in this scenario compiler still have to improve and should identify (Integer... i) for method(2) IMO.

unfortunately javac6 fails to do that. . As of now, I personally avoid var-arg overloaded.

[gurpeet singh]

Don Redd wrote:Hi

i am little confused with below pieces of code.

case1:
the code below is working fine!

public void method(Integer i){System.out.println("Boxed");}
public void method(int i){System.out.println("Primitive");}

//upon invocation of below statement
method(2);//output is : Primitive ; which is understandable

case2:
but,why is below code giving compile time error saying ambiguous call as both methods match invocation

public void method(Integer... i){System.out.println("Boxed");}
public void method(int... i){System.out.println("Primitive");}

//upon invocation of below statement
method(2);//output is : compile time error, ambiguous invocation.

Can someone explain whats going on in case 2,

Thanks,
Don,Redd...

This is because compiler is unable to find the MOST SPECIFIC METHOD. as to answer what is a most specific method you can check the SCJP FAQ'S or there is really a nice article at Corey's SCJP Timeline at http://radio.javaranch.com/corey/2004/08/19/1092931618000.html.

[Don Redd]

Thanks, Seetharaman and Gurpeet !!

[Don Redd]

Java says that in order to support pre java5 functionality/code , compiler gives least priority to widening, boxing and var-args,

and I am happy of compiler behavior with widening and boxing. but not with var-args

void method(int i){System.out.println("Primitive");}
void method(int... i){System.out.println("Var-args");}

//when I use below invocation
method(22);//output is :---> Var-args; 
 

Compiler is breaking the promise at line no 5.
Can someone help me understanding this behavior.

[gurpeet singh]

Don Redd wrote:

Java says that in order to support pre java5 functionality/code , compiler gives least priority to widening, boxing and var-args,

and I am happy of compiler behavior with widening and boxing. but not with var-args

void method(int i){System.out.println("Primitive");}
void method(int... i){System.out.println("Var-args");}

//when I use below invocation
method(22);//output is :---> Var-args; 
 

Compiler is breaking the promise at line no 5.
Can someone help me understanding this behavior.

no there is no breaking of promise. widening wins over boxing, widening wins over var-args, boxing wins over var-args. in short var-args is always the looser. here there is no such case. here the problem is of most specific method. in this case the most specific method is the one taking int i as the parameter. had you read the corey's most specific method (i gave link earlier) you would have been able to answer this question. nonetheless, the most specific method is the one with int i as parameter , because its values can be ACCOMODATED by the method with the var-args parameter but not vice-versa.

[Don Redd]

gurpeet singh wrote:


no there is no breaking of promise. widening wins over boxing, widening wins over var-args, boxing wins over var-args. in short var-args is always the looser. here there is no such case. here the problem is of most specific method. in this case the most specific method is the one taking int... i as the parameter. had you read the corey's most specific method (i gave link earlier) you would have been able to answer this question. nonetheless, the most specific method is the one with var-args as parameter as it can take 0 or more ints, whereas the method with int i as parameter can take just one int.

hmm, i have gone through corey's theory on most specific method, before posting above behavior,
1)
lets say there two things A and B, if A fits in B & B doesn't fits into A,then we call A is Specific and B is Generic.(This is what corey's says) in the example he has given; you can fit (int, int,long) into (int,long,long) but onto reverse because of second argument....

similarly in this case, int is specific where as int... is generic as per reason given above,so my take is that program should have printed "Primitive"...............as per most specific method theory.

2)Compiler breaks promise here because, lets say I have written method(int i) at the time of java 1.4 and now I am using same code with java 6 compiler and adding new method(int i...) will cause problem here

hope I posted my query in understandable way

[gurpeet singh]

i think i have wrongly posted my earlier query . yes you are right the method with the int arguments is the one which is most specific method. and hence the output should be Primitive as opposed to what you have written. i ran the program on my system and it gave me output PRIMITIVE thus confirming that the method with the int parameter is indeed the most specific method.

[Don Redd]

Yes, its printing Primitive on my personal machine at home, have to check tomorrow why my office workstation confused me ,anyways thanks Gurpeet !!!

[gurpeet singh]

Don Redd wrote:Yes, its printing Primitive on my personal machine at home, have to check tomorrow why my office workstation confused me ,anyways thanks Gurpeet !!!

You are Welcome Don

[Peter Piddle]

Dear Don,
Seems like your query is already clarified.
HTH,

[Shalini Srivastav]

public class Test
{
    public static void doIt(int a, long b, long c)
    {
        System.out.println("In doIt(int, long, long)");
    }
    
    public static void doIt(long a, int b, int c)
    {
        System.out.println("In doIt(long, int, int)");
    }
    
    public static void main(String[] args)
    {
        doIt(1, 2, 3);
    }
}

What is the result of compiling and executing the above code?

A. Prints "In doIt(int, long, long)"
B. Prints "In doIt(long, int, int)"
C. Compiler Error
D. Run-Time Error

It is said there is no specific method for doIt(123); why ? second method has two int parameters however first one has only one.it is not enough to be a specific method ?

http://radio.javaranch.com/corey/2004/08/19/1092931618000.html

[Don Redd]

if you try to fit this arguments (int a, long b, long c) in to this set of arguments (long a, int b, int c) second and third arguments conflict because long cannot be fit into int
now the other way
if you try to fit this arguments (long a, int b, int c) in to this set (int a, long b, long c) of arguments first argument conflicts because long cannot be fit into int


so there is no specific or generic method here, just ambiguity

[Pritish Chakraborty]

@Shalini : Try your method call with (1L, 2, 3) or (1, 2L, 3L).

[Shalini Srivastav]

Don Redd wrote:if you try to fit this arguments (int a, long b, long c) in to this set of arguments (long a, int b, int c) second and third arguments conflict because long cannot be fit into int
now the other way
if you try to fit this arguments (long a, int b, int c) in to this set (int a, long b, long c) of arguments first argument conflicts because long cannot be fit into int


so there is no specific or generic method here, just ambiguity

I don't know when i tried to fit long into int ? these all are int not long doIt(1, 2, 3);

[Don Redd]

you can replace word 'you' with 'compiler' , the above checks are done by compiler to find out most specific method for your invocation, but it could not find any specific method!!!

[Pritish Chakraborty]

Don Redd wrote:

In this context, your emoticon seems very cheeky..lol.

[Shalini Srivastav]

Don Redd wrote: you can replace word 'you' with 'compiler' , the above checks are done by compiler to find out most specific method for your invocation, but it could not find any specific method!!!

Yes but my question is still as it is when i tried to pass long value ? so compiler getting trouble to fit long into int ? doIt(1, 2, 3);

[Pritish Chakraborty]

When you pass whole numbers within the range of an integer, they are always treated as integers.

Basically you are trying to pass three integers into methods, none of which take three integers.

This is not C++, they won't be implicitly converted to long unless you apply the L suffix or a cast.

When the number is larger/smaller than an integer, the L suffix becomes necessary or the compiler gives an error.

[Shalini Srivastav]

Pritish Chakraborty wrote:When you pass whole numbers within the range of an integer, they are always treated as integers.

Basically you are trying to pass three integers into methods, none of which take three integers.

This is not C++, they won't be implicitly converted to long unless you apply the L suffix or a cast.

When the number is larger/smaller than an integer, the L suffix becomes necessary or the compiler gives an error.

for doIt(1,2,3);
second method has two int parameters however first one has only one.is it not enough to be a specific method for second method?

[Pritish Chakraborty]

The answer is already known...

No, the compiler will not convert that one integer into a long for you. You have to do it yourself!

[Shalini Srivastav]

Pritish Chakraborty wrote:The answer is already known...

No, the compiler will not convert that one integer into a long for you. You have to do it yourself!

public class Test
{
    public static void doIt(int a, long b, long c)
    {
        System.out.println("In doIt(int, long, long)");
    }
    
    public static void doIt(int a, int b, long c)
    {
        System.out.println("In doIt(int, int, long)");
    }
    
    public static void main(String[] args)
    {
        doIt(1, 2, 3);
    }
}

What is the result of compiling and executing the above code?

public class Test
{
    public static void doIt(int a, long b, long c)
    {
        System.out.println("In doIt(int, long, long)");
    }
    
    public static void doIt(int a, int b, long c)
    {
        System.out.println("In doIt(int, int, long)");
    }
    
    public static void main(String[] args)
    {
        doIt(1, 2, 3);
    }
}

What is the result of compiling and executing the above code?

Prints "In doIt(int, int, long)"

you can see here there are two int so compiler is converting one int (three) into long why ? as you said compiler shouldn't convert this ?

[Pritish Chakraborty]

I was talking about that one method...

Let us clarify things. We will have to do a few test cases.

1. First, remove one of the methods and try to perform the call to doIt(). The compiler will pass successfully because the most specific method is the only one given (should be the case).

2. When the two methods compete with each other, the more specific one is the one accepting the most integers (considering that the compiler is still treating the passed numbers as integers). Hence the method with two ints is selected. In this case, yes, the compiler does perform the implicit widening conversion. Had it been a narrowing conversion, I don't think the compiler would have allowed it (for example, from int to short).

[Don Redd]

Hi Shalini,

Going back to your first post, you mentioned one method is taking two int's and it shall be specific.

the meaning of specific is little different than what you are thinking.


lets say you have two methods

void doo(float f, double d)

void doo(double f, double d) 

and when you invoke doo(1,2); then compiler cannot find method of signature doo(int,int) but still it compiles and executes method doo(float f,double d) because of the two methods given one above this one specific.( applying same logic mentioned before)


in below case the compiler fails to find specific method( applying same logic mentioned before) for the invocation doo(1,2) . and gives compiler error.......

void doo(float f, double d)

void doo(double f, float f) 

[Pritish Chakraborty]

Don, on the IDEone compiler (http://www.ideone.com), the (float f, float d) method was selected when I tried to pass (1,2)...

Ah, I see now that you have edited your post. The most specific method here is the one with matching argument types?

That is, either (float f, float d) or (double f, double d), whichever one you insert independently...

Strange are the compiler's ways.

[Shalini Srivastav]

Don Redd wrote:Hi Shalini,

Going back to your first post, you mentioned one method is taking two int's and it shall be specific.

the meaning of specific is little different than what you are thinking.


lets say you have two methods

void doo(float f, double d)

void doo(double f, double d) 

and when you invoke doo(1,2); then compiler cannot find method of signature doo(int,int) but still it compiles and executes method doo(float f,double d) because of the two methods given one above this one specific.( applying same logic mentioned before)


in below case the compiler fails to find specific method( applying same logic mentioned before) for the invocation doo(1,2) . and gives compiler error.......

void doo(float f, double d)

void doo(double f, float f) 

yes this is good one.

[Shalini Srivastav]

now i invented a rule i.e cross parameters can't be compile.

m1(int,double)
m1(double,int)