Ambiguous overloaded java methods with generics and varargs

generics, java, variadic-functions

Solution

An intuitive way to test whether `method1` is more specific than `method2` is to see whether `method1` can be implemented by invoking `method2` with the same parameters

method1(params1){
    method2(params1);   // if compiles, method1 is more specific than method2
}

If there are varargs, we may need to expand a vararg so that 2 methods have same number of params.

Let's check the first two `method()`s in your example

<K> void method_a(K arg, Object... otherArgs) {
    method_b(arg, otherArgs);   //ok L1
}
<K> void method_b(Object arg, Object... otherArgs) { // extract 1 arg from vararg
    method_a(arg, otherArgs);   //ok L2
}

(return types are not used in determining specificity, so they are omitted)

Both compile, therefore each is more specific than the other, hence the ambiguity. Same goes for your `method2()`s, they are more specific than each other. Therefore the call to `method2()` is ambiguous and shouldn't compile; otherwise it's a compiler bug.

So that's what the spec says; but is it proper? Certainly, `method_a` looks more specific than `method_b`. Actually if we have a concrete type instead of `K`

void method_a(Integer arg, Object... otherArgs) {
    method_b(arg, otherArgs);   // ok
}
void method_b(Object arg, Object... otherArgs) {
    method_a(arg, otherArgs);   // error
}

then only `method_a` is more specific than `method_b`, not vice versa.

The discrepancy arises from the magic of type inference. `L1`/`L2` calls a generic method without explicit type arguments, so the compiler tries to infer the type arguments. The goal of type inference algorithm is to find type arguments such that the code compiles! No wonder L1 and L2 compile. L2 is actually infer to be `this.<Object>method_a(arg, otherArgs)`

Type inference tries to guess what the programmer wants, but the guess must be wrong sometimes. Our real intention is actually

<K> void method_a(K arg, Object... otherArgs) {
    this.<K>method_b(arg, otherArgs);   // ok
}
<K> void method_b(Object arg, Object... otherArgs) {
    this.<K>method_a(arg, otherArgs);   // error
}

Problem

I'm trying to understand how java deals with ambiguities in function calls. In the following code, the call to `method` is ambiguous, but `method2` is not!!!. I feel both are ambiguous, but why does this compile when I comment out the call to `method`? Why is `method2` not ambiguous as well? ``` public class A { public static <K> List<K> method(final K arg, final Object... otherArgs) { System.out.println("I'm in one"); return new ArrayList<K>(); } public static <K> List<K> method(final Object... otherArgs) { System.out.println("I'm in two"); return new ArrayList<K>(); } public static <K, V> Map<K, V> method2(final K k0, final V v0, final Object... keysAndValues) { System.out.println("I'm in one"); return new HashMap<K,V> (); } public static <K, V> Map<K, V> method2(final Object... keysAndValues) { System.out.println("I'm in two"); return new HashMap<K,V>(); } public static void main(String[] args) { Map<String, Integer> c = A.method2( "ACD", new Integer(4), "DFAD" ); //List<Integer> d = A.method(1, "2", 3 ); } } ``` EDIT: This came up in comments: A number of IDEs report both as ambiguous - IntelliJ and Netbeans so far. However, it compiles just fine from command-line/maven.

Original source

Related problems