When you invoke an overloaded method overloading resolution takes place. This can be quite involved depending on the methods in the overloaded set. It is possible that there are several candidate methods for the specific invocation (given the arguments used in the invocation) but that none of them is the most specific, as in this case.
In this case, you are calling the method with an int argument. The two candidate methods are both variable-arity, so both of them remain as candidates. If one of them had been fixed-arity, that would have been chosen, as variable-arity is the last resort when determining which overloaded method to call.
At this point you must look to see if the types of the parameters in each method is such that one of the types could be assigned to the other. In that case, the method with the parameter of the type that could be assigned to the other method's parameter type wins, since it is more specific.
In your case, long can't be assigned to Integer, and Integer can't be assigned to long (at least not without unboxing the Integer first.) Then you are left with two methods and none of them is the best candidate, that's why you have ambiguity and the compiler gives you an error.
To clarify this point, the following works, because you can assign an Integer instance to a Number reference variable with no autoboxing or casting (The assignment uses an implicit widening conversion.)
The rules for method overload resolution are explained in mathematical-like strictness in the
Java Language Specification, but you can look at The Java Programming Language for a more accessible (although more simplified) approach.
[ December 17, 2008: Message edited by: Ruben Soto ]
[ December 17, 2008: Message edited by: Ruben Soto ]