Ambiguous method in Java 8, why? [duplicate]

This question already has an answer here:

Java type inference: reference is ambiguous in Java 8, but not Java 7 2 answers

public static void main(String... args){
    then(bar()); // Compilation Error
}

public static <E extends Exception> E bar() {
    return null;
}

public static void then(Throwable actual) { }

public static void then(CharSequence actual) { }

Compilation result (from command line javac Ambiguous.java)

Ambiguous.java:4: error: reference to then is ambiguous
        then(bar());
        ^
  both method then(Throwable) in Ambiguous and method then(CharSequence) in Ambiguous match
1 error

Why this method is ambiguous? This code compile with success under Java 7!

After changing method bar to:

public static <E extends Float> E bar() {
    return null;
}

This compiles without any problems, but is reported as error in IntelliJ Idea (Cannot resolve method then(java.lang.FLoat)).

This code fails under Java 7 - javac -source 1.7 Ambiguous.java:

Ambiguous.java:4: error: no suitable method found for then(Float)
        then(bar());
        ^
    method Ambiguous.then(Throwable) is not applicable
      (argument mismatch; Float cannot be converted to Throwable)
    method Ambiguous.then(CharSequence) is not applicable
      (argument mismatch; Float cannot be converted to CharSequence)
1 error

Java version

java version "1.8.0_40"
Java(TM) SE Runtime Environment (build 1.8.0_40-b25)
Java HotSpot(TM) 64-Bit Server VM (build 25.40-b25, mixed mode)

Consider the following class:

public class Foo extends Exception implements CharSequence {
    //...
}

The class Foo implements both Throwable and CharSequence. So in case E is set to this instance, the Java compiler does not know which method to call.

The reason there is probably no problem for Java7 is that generics are less implemented. In case you don't provide an E yourself (e.g. (Foo) bar()), Java will fall back on the basic verion of E which is implements Exception, E is thus only considered to be an instance of Exception.

In Java8, the type inference is improved, the type of E is now derived from the parameter called for by then(), in other words the compiler first looks what possible types then() needs, the problem is that they both are valid choices. So in that case it becomes ambiguous.

Proof of concept:

Now we will slightly modify your code and show how ambiguous calls are resolved:

Say we modify the code to:

public class Main {
    public static void main(String... args){
        then(bar()); // Compilation Error
    }
    public static <E extends Exception> E bar() {
        return null;
    }
    public static void then(CharSequence actual) {
        System.out.println("char");
    }
}

If you run this in Java8, there is no problem (it prints char), because Java8 simply assumes there is such class Foo (it created some kind of "inner" type for it that derived from both).

Running this in Java7 yields problems:

/MyClass.java:18: error: method then in class MyClass cannot be applied to given types;
    then(bar()); // Compilation Error
    ^
  required: CharSequence
  found: Exception
  reason: actual argument Exception cannot be converted to CharSequence by method invocation conversion
1 error

It did a fallback on Exception and couldn't find a type that could deal with it.

If you run the original code in Java8, it will error because of the ambiguous call, if you run it in Java7 however, it will use the Throwable method.

In short: the compiler aims to "guess" what E is in Java8, whereas in Java7 the most conservative type was picked.