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.