I'm trying to understand how java deals with ambiguities in function calls. In the following code, the call to
method
method2
method
method2
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 );
}
}
An intuitive way to test whether method1
is more specific than metho2
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
}