Итак, перегрузка метода - это плохо. Теперь, когда это было решено, давайте предположим, что я на самом делехочу перегрузить такой метод:

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

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

В Java 7 я мог бы легко вызывать их с не двусмысленными анонимными классами в качестве аргументов:

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

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

Теперь в Java 8 я бы хотел вызвать эти методы с лямбда-выражениями, конечно, и я могу!

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

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

Поскольку компилятордолжен быть в состоянии сделать выводIntegerпочему бы мне не уйтиInteger отсюда?

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

// Function
run(i -> 1);

Но это не компилируется. Компилятору (javac, jdk1.8.0_05) это не нравится:

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

Для меня, интуитивно, это не имеет смысла. Нет абсолютно никакой двусмысленности между лямбда-выражением, которое возвращает возвращаемое значение («совместимое по значению»), и лямбда-выражением, которое даетvoid («void-совместимый»), как указано вJLS §15.27.

Но, конечно, JLS является глубоким и сложным, и мы унаследовали 20-летнюю историю обратной совместимости, и есть новые вещи, такие как:

Определенные выражения аргумента, которые содержатнеявно типизированные лямбда-выражения (§15.27.1) или неточные ссылки на метод (§15.13.1) игнорируются тестами применимости, поскольку их значение не может быть определено до тех пор, пока не будет выбран целевой тип.

из JLS §15.12.2

Вышеуказанное ограничение, вероятно, связано с тем, чтоJEP 101 не было реализовано полностью, как видноВот а такжеВот.

Вопрос:

Кто может сказать мне, какие именно части JLS определяют эту неоднозначность во время компиляции (или это ошибка компилятора)?

Бонус: Почему все было решено таким образом?

Обновить:

С jdk1.8.0_40 вышеописанное компилируется и работает нормально