OK, entonces la sobrecarga de métodos es una mala cosa ™. Ahora que esto se ha resuelto, supongamos que realmentequerer para sobrecargar un método como este:

static void run(Consumer<Integer> consumer) {
    System.out.println("consumer");
}

static void run(Function<Integer, Integer> function) {
    System.out.println("function");
}

En Java 7, podría llamarlos fácilmente con clases anónimas no ambiguas como argumentos:

run(new Consumer<Integer>() {
    public void accept(Integer integer) {}
});

run(new Function<Integer, Integer>() {
    public Integer apply(Integer o) { return 1; }
});

Ahora en Java 8, me gustaría llamar a esos métodos con expresiones lambda, por supuesto, ¡y puedo!

// Consumer
run((Integer i) -> {});

// Function
run((Integer i) -> 1);

Desde el compiladordebería ser capaz de inferirIntegerpor que no me voyInteger lejos, entonces?

// Consumer
run(i -> {});

// Function
run(i -> 1);

Pero esto no se compila. Al compilador (javac, jdk1.8.0_05) no le gusta eso:

Test.java:63: error: reference to run is ambiguous
        run(i -> {});
        ^
  both method run(Consumer<Integer>) in Test and 
       method run(Function<Integer,Integer>) in Test match

Para mí, intuitivamente, esto no tiene sentido. No hay absolutamente ninguna ambigüedad entre una expresión lambda que produce un valor de retorno ("compatible con el valor") y una expresión lambda que producevoid ("compatible con el vacío"), como se establece en elJLS §15.27.

Pero, por supuesto, el JLS es profundo y complejo y heredamos 20 años de historial de compatibilidad con versiones anteriores, y hay cosas nuevas como:

Ciertas expresiones de argumento que contienenexpresiones lambda escritas implícitamente (§15.27.1) o referencias de métodos inexactos (§15.13.1) son ignorados por las pruebas de aplicabilidad, porque su significado no puede determinarse hasta que se seleccione un tipo de objetivo.

de JLS §15.12.2

La limitación anterior probablemente esté relacionada con el hecho de queJEP 101 no se implementó completamente, como se puede veraquí yaquí.

Pregunta:

¿Quién puede decirme exactamente qué partes del JLS especifica esta ambigüedad en tiempo de compilación (o es un error del compilador)?

Bonus: ¿Por qué se decidieron las cosas de esta manera?

Actualizar:

Con jdk1.8.0_40, lo anterior se compila y funciona bien