Выбор сигнатуры метода для лямбда-выражения с несколькими совпадающими типами целей

Я отвечал на вопрос и столкнулся со сценарием, который я не могу объяснить. Рассмотрим этот код:

interface ConsumerOne<T> {
    void accept(T a);
}

interface CustomIterable<T> extends Iterable<T> {
    void forEach(ConsumerOne<? super T> c); //overload
}

class A {
    private static CustomIterable<A> iterable;
    private static List<A> aList;

    public static void main(String[] args) {
        iterable.forEach(a -> aList.add(a));     //ambiguous
        iterable.forEach(aList::add);            //ambiguous

        iterable.forEach((A a) -> aList.add(a)); //OK
    }
}

Я не понимаю, почему при явном вводе параметра лямбда (A a) -> aList.add(a)-кода код компилируется. Кроме того, почему это связано с перегрузкой в, Iterableа не в CustomIterable?
Есть ли какое-то объяснение этому или ссылка на соответствующий раздел спецификации?

Примечание: iterable.forEach((A a) -> aList.add(a));компилируется только при CustomIterable<T>расширении Iterable<T>(полная перегрузка методов CustomIterableприводит к неоднозначной ошибке)

Получение этого на обоих:

• openjdk версия "13.0.2" 2020-01-14
  Компилятор Eclipse
• openjdk версия "1.8.0_232"
  компилятор Eclipse

Изменить : Приведенный выше код не компилируется при сборке с Maven, в то время как Eclipse успешно компилирует последнюю строку кода.

TL; DR, это ошибка компилятора.

Не существует правила, которое бы отдавало приоритет конкретному применимому методу, когда он наследуется, или методу по умолчанию. Интересно, когда я меняю код на

interface ConsumerOne<T> {
    void accept(T a);
}
interface ConsumerTwo<T> {
  void accept(T a);
}

interface CustomIterable<T> extends Iterable<T> {
    void forEach(ConsumerOne<? super T> c); //overload
    void forEach(ConsumerTwo<? super T> c); //another overload
}

iterable.forEach((A a) -> aList.add(a));оператор выдает ошибку в Eclipse.

Поскольку ни одно свойство forEach(Consumer<? super T) c)метода из Iterable<T>интерфейса не изменилось при объявлении другой перегрузки, решение Eclipse выбрать этот метод не может (последовательно) основываться на каком-либо свойстве метода. Это все еще единственный унаследованный метод, все еще единственный defaultметод, все еще единственный метод JDK и так далее. В любом случае ни одно из этих свойств не должно влиять на выбор метода.

Обратите внимание, что изменение объявления на

interface CustomIterable<T> {
    void forEach(ConsumerOne<? super T> c);
    default void forEach(ConsumerTwo<? super T> c) {}
}

также выдает «неоднозначную» ошибку, поэтому число применимых перегруженных методов также не имеет значения, даже если есть только два кандидата, нет общего предпочтения в отношении defaultметодов.

До сих пор проблема, кажется, появляется, когда есть два применимых метода и defaultметод и отношения наследования, но это не правильное место, чтобы копать дальше.

Но понятно, что конструкции вашего примера могут обрабатываться другим кодом реализации в компиляторе, один демонстрирует ошибку, а другой нет.
a -> aList.add(a)является неявно типизированным лямбда-выражением, которое нельзя использовать для разрешения перегрузки. Напротив, (A a) -> aList.add(a)это явно типизированное лямбда-выражение, которое можно использовать для выбора подходящего метода из перегруженных методов, но здесь это не помогает (здесь не должно помогать), поскольку все методы имеют типы параметров с одинаковой функциональной сигнатурой. ,

В качестве контр-примера, с

static void forEach(Consumer<String> c) {}
static void forEach(Predicate<String> c) {}
{
  forEach(s -> s.isEmpty());
  forEach((String s) -> s.isEmpty());
}

функциональные сигнатуры различаются, и использование лямбда-выражения явно типа может действительно помочь в выборе правильного метода, тогда как неявно типизированное лямбда-выражение не помогает, поэтому forEach(s -> s.isEmpty())выдает ошибку компилятора. И все компиляторы Java согласны с этим.

Обратите внимание, что aList::addэто неоднозначная ссылка на addметод, так как метод также перегружен, поэтому он также не может помочь в выборе метода, но ссылки на методы в любом случае могут обрабатываться другим кодом. Переключение на однозначное aList::containsили изменения Listв Collection, чтобы сделать addоднозначный, не изменить результат в моей установке Eclipse , (я 2019-06).

Компилятор Eclipse правильно разрешает defaultметод , поскольку это наиболее специфический метод в соответствии со спецификацией языка Java 15.12.2.5 :

Если точно один из максимально специфических методов является конкретным (то есть не по abstractумолчанию), это наиболее специфический метод.

javac(используется Maven и IntelliJ по умолчанию) говорит, что вызов метода здесь неоднозначен. Но в соответствии со спецификацией языка Java это не является двусмысленным, так как один из двух методов является наиболее конкретным здесь.

Неявно типизированный лямбда-выражения обрабатываются иначе, чем явно типизированные лямбда-выражения в Java. Неявно типизированные, в отличие от явно типизированных лямбда-выражений, проходят первую фазу, чтобы идентифицировать методы строгого вызова (см. Спецификацию языка Java jls-15.12.2.2 , первая точка). Следовательно, вызов метода здесь неоднозначен для неявно типизированных лямбда-выражений.

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

iterable.forEach((ConsumerOne<A>) aList::add);

или

iterable.forEach((Consumer<A>) aList::add);

Вот ваш пример, дополнительно свернутый для тестирования:

class A {

    interface FunctionA { void f(A a); }
    interface FunctionB { void f(A a); }

    interface FooA {
        default void foo(FunctionA functionA) {}
    }

    interface FooAB extends FooA {
        void foo(FunctionB functionB);
    }

    public static void main(String[] args) {
        FooAB foo = new FooAB() {
            @Override public void foo(FunctionA functionA) {
                System.out.println("FooA::foo");
            }
            @Override public void foo(FunctionB functionB) {
                System.out.println("FooAB::foo");
            }
        };
        java.util.List<A> list = new java.util.ArrayList<A>();

        foo.foo(a -> list.add(a));      // ambiguous
        foo.foo(list::add);             // ambiguous

        foo.foo((A a) -> list.add(a));  // not ambiguous (since FooA::foo is default; javac bug)
    }

}

Код, в котором Eclipse реализует JLS §15.12.2.5, не находит ни один метод более специфичным, чем другой, даже в случае явно лямбда с типизированным типом.

Так что в идеале «Затмение» остановится здесь и сообщит о двусмысленности. К сожалению, реализация разрешения перегрузки имеет нетривиальный код в дополнение к реализации JLS. Насколько я понимаю, этот код (который датируется временем, когда Java 5 была новой) должен быть сохранен, чтобы заполнить некоторые пробелы в JLS.

Я подал https://bugs.eclipse.org/562538, чтобы отследить это.

Независимо от этой конкретной ошибки, я могу только настоятельно рекомендовать против этого стиля кода. Перегрузка хороша для большого количества неожиданностей в Java, умноженная на вывод типа лямбда, сложность совершенно непропорциональна полученному усилению.