I noticed today that auto-boxing can sometimes cause ambiguity in method overload resolution. The simplest example appears to be this:
public class Test {
When you say f(a, b), the compiler is confused as to which function it should reference to.
This is because a is an int, but the argument expected in f is an Object. So the compliler decides to convert a to an Object. Now the problem is that, if a can be converted to an object, so can be b.
This means that the function call can reference to either definitions. This makes the call ambiguous.
When you convert a to an Object manually, the compiler just looks for the closest match and then refers to it.
Why didn't the compiler select the function that can be reached by "doing the least possible number of boxing/unboxing conversions"?
See the following case:
f(boolean a, Object b)
f(Object a , boolean b)
If we call like f(boolean a, boolean b), which function should it select? It ambigous right? Similarly, this will become more complex when a lot of arguments are present. So the compiler chose to give you a warning instead.
Since there is no way to know which one of the functions the programmer really intended to call, the compiler gives an error.