Вибір підпису методу для вираження лямбда з кількома типовими цільовими типами

Я відповідав на запитання і наткнувся на сценарій, який я не можу пояснити. Розглянемо цей код:

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, помножених на умови лямбда-виводу, складність є досить непропорційною WR від сприйнятого посилення.