Java 5.0 Auto Boxing/Unboxing and Method Selection in Overloaded Methods

[Tapas Kumar]

Hi Everybody,
I am having difficulty in understanding how "Most Specific" method selction occurs keeping in mind that java 5.0 supports auto boxing/unboxing during the process.for example why some of the method call are giving compile error(because of ambigous method call) and some are not?
Could someone please explain ?
Thanks in advance
Tapas

---------------------
import static java.lang.System.*;

class A {
public static void main(String[] args) {
m1(new Integer(4), 5); //1 Comppile error
m1(4, 5); //2 This line is OK
m1(new Integer(4), new Integer(5)); //3 Compile error
m1(4, new Integer(5)); //4 This line is OK
}

private static void m1(int i, Integer iRef) {
out.println(" ==> (int, Integer)");
}

private static void m1(int i, int j) {
out.println(" ==> (int, int)");
}

}

---------------------

[Duong Nguyen Huy]

At compile time, if there are more than one options to select method to be executed (ofcourse after un/autoboxing), compile time error flag will turn on.

[Tapas Kumar]

Hi Duong,
Thanks for your response.But we all know what you said.But could you elaborate for example why line //1 is giving ambigous method error but not lline //4? when exactly for eample autoboxing/unboxing take effect? before most specifict method selection or after most specific method selection?
Anyone?
Thanks

[John Beavers]

Second guessing the compiler, I would say that there are two unique
m1() methods that apply to two of the method calls. Auto boxing and
unboxing is a Java 5 goodie that would work, but which method would be
used? When both work, it is ambiguous. Pretty smart compiler, I think.

[Wensheng Li]

The general rules for Autoboxing/unboxing in the context of method overloading are:

1)If the given arguments match perfectly the parameter list, like "m1(4, 5)" matching "m1(int i, int j)" and "m1(4, new Integer(5))" matching "m1(int i,Integer iRef") in this example. The method selection happens trivially as expected.No autoboxing/unboxing is necessary.

2)If there is no method whose signature matches the given argument perfectly, the comiler will use autoboxing/unboxing to seize any chance of finding any possible matches.For example,
For "m1(new Integer(4), 5)", if its first arguement is unboxed, it will matches "m1(int i,int j)"

3)More specificall,the compiler will try all possible autoboxing/unboxing options(combinations) to find matches. For example,
given "m1(new Integer(4), 5)", the compiler will try 3 options, namely:
concerting it into :"m1(new Integer(4), new Integer(5))" or
"m1(4, 5)" or
"m1(4, new Integer(5))"

As you can see, converting "m1(new Integer(4), 5)" into "m1(4,5)" or into "m1(4,new Integer(5)" will BOTH find a match.

That's why "m1(new Integer(4), 5)" won't compiles.

So the rule is: If there are more than two matches found in this search, the comiler will complain "It is ambigous!!!"

Interestingly ,even if we as human could ditinguish that it takes less effort to convert "m1(new Integer(4), 5)" into "m1(4,5)" than into "m1(4,new Integer(5))" to find a match. The compiler simply could NOT tell.He hesitantly managed to decide which approach to take and then complain.

So it is actually not so smart.

[Tapas Kumar]

Thanks everyone in particular Li for clearing up my doubt.
As you said looks like java compliler does NOT care about which convertion takes "Less Effort" when auto boxing/unboxing.
Regards
Tapas