Auswahl der Methodensignatur für den Lambda-Ausdruck mit mehreren übereinstimmenden Zieltypen

Ich beantwortete eine Frage und stieß auf ein Szenario, das ich nicht erklären kann. Betrachten Sie diesen Code:

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
    }
}

Ich verstehe nicht, warum das explizite Eingeben des Parameters des Lambda (A a) -> aList.add(a)den Code kompilieren lässt. Warum ist es außerdem Iterableeher mit der Überlastung als mit der Überlastung verbunden CustomIterable?
Gibt es eine Erklärung dafür oder einen Link zu dem relevanten Abschnitt der Spezifikation?

Hinweis: iterable.forEach((A a) -> aList.add(a));Kompiliert nur, wenn es CustomIterable<T>erweitert wird Iterable<T>(eine flache Überladung der Methoden CustomIterableführt zu einem mehrdeutigen Fehler).

Bekomme das auf beiden:

• openjdk Version "13.0.2" 2020-01-14
  Eclipse Compiler
• openjdk version "1.8.0_232"
  Eclipse-Compiler

Bearbeiten : Der obige Code kann beim Erstellen mit maven nicht kompiliert werden, während Eclipse die letzte Codezeile erfolgreich kompiliert.

TL; DR, dies ist ein Compiler-Fehler.

Es gibt keine Regel, die einer bestimmten anwendbaren Methode Vorrang einräumt, wenn sie vererbt wird, oder einer Standardmethode. Interessanterweise, wenn ich den Code auf ändere

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
}

Die iterable.forEach((A a) -> aList.add(a));Anweisung erzeugt einen Fehler in Eclipse.

Da sich beim Deklarieren einer weiteren Überladung keine Eigenschaft der forEach(Consumer<? super T) c)Methode über die Iterable<T>Schnittstelle geändert hat, kann die Entscheidung von Eclipse, diese Methode auszuwählen, nicht (konsistent) auf einer Eigenschaft der Methode basieren. Es ist immer noch die einzige geerbte Methode, immer noch die einzige defaultMethode, immer noch die einzige JDK-Methode und so weiter. Keine dieser Eigenschaften sollte sich ohnehin auf die Methodenauswahl auswirken.

Beachten Sie, dass Sie die Deklaration in ändern

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

erzeugt auch einen "mehrdeutigen" Fehler, so dass die Anzahl der anwendbaren überladenen Methoden ebenfalls keine Rolle spielt, selbst wenn es nur zwei Kandidaten gibt, gibt es keine allgemeine Präferenz für default Methoden.

Bisher scheint das Problem aufzutreten, wenn zwei anwendbare Methoden vorhanden sind und eine defaultMethode und eine Vererbungsbeziehung beteiligt sind, aber dies ist nicht der richtige Ort, um weiter zu graben.

Es ist jedoch verständlich, dass die Konstrukte Ihres Beispiels möglicherweise von unterschiedlichem Implementierungscode im Compiler verarbeitet werden, wobei einer einen Fehler aufweist, der andere jedoch nicht.
a -> aList.add(a)ist ein implizit typisierter Lambda-Ausdruck, der nicht für die Überlastungsauflösung verwendet werden kann. Im Gegensatz dazu (A a) -> aList.add(a)handelt es sich um einen explizit typisierten Lambda-Ausdruck, mit dem eine übereinstimmende Methode aus den überladenen Methoden ausgewählt werden kann. Dies hilft hier jedoch nicht (sollte hier nicht helfen), da alle Methoden Parametertypen mit genau derselben funktionalen Signatur haben .

Als Gegenbeispiel mit

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

Die funktionalen Signaturen unterscheiden sich, und die Verwendung eines explizit eingegebenen Lambda-Ausdrucks kann in der Tat bei der Auswahl der richtigen Methode hilfreich sein, während der implizit typisierte Lambda-Ausdruck nicht hilfreich ist und daher forEach(s -> s.isEmpty())einen Compilerfehler erzeugt. Und alle Java-Compiler sind sich einig.

Beachten Sie, dass dies aList::addeine mehrdeutige Methodenreferenz ist, da die addMethode ebenfalls überladen ist, sodass sie auch bei der Auswahl einer Methode helfen kann. Methodenreferenzen werden jedoch möglicherweise trotzdem von einem anderen Code verarbeitet. Das Wechseln zu einer eindeutigen aList::containsoder das Ändern Listzu Collection, um addeindeutig zu machen , hat das Ergebnis in meiner Eclipse-Installation (die ich verwendet habe 2019-06) nicht geändert .

Der Eclipse-Compiler wird korrekt in die defaultMethode aufgelöst , da dies die spezifischste Methode gemäß der Java-Sprachspezifikation 15.12.2.5 ist :

Wenn genau eine der maximal spezifischen Methoden konkret ist (dh nicht abstractoder standardmäßig), ist dies die spezifischste Methode.

javac(wird standardmäßig von Maven und IntelliJ verwendet) teilt mit, dass der Methodenaufruf hier nicht eindeutig ist. Laut Java Language Specification ist dies jedoch nicht mehrdeutig, da eine der beiden Methoden hier die spezifischste ist.

Implizit typisierte Lambda-Ausdrücke werden anders behandelt als explizit typisierte Lambda-Ausdrücke in Java. Implizit typisiert im Gegensatz zu explizit typisierten Lambda-Ausdrücken durchlaufen die erste Phase, um die Methoden des strengen Aufrufs zu identifizieren (siehe Java-Sprachspezifikation jls-15.12.2.2 , erster Punkt). Daher ist der Methodenaufruf hier für implizit typisierte Lambda-Ausdrücke nicht eindeutig .

In Ihrem Fall besteht die Problemumgehung für diesen javacFehler darin, den Typ der Funktionsschnittstelle anzugeben , anstatt einen explizit typisierten Lambda-Ausdruck wie folgt zu verwenden:

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

oder

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

Hier ist Ihr Beispiel zum Testen weiter minimiert:

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)
    }

}

Der Code, in dem Eclipse JLS §15.12.2.5 implementiert, findet keine der beiden Methoden spezifischer als die andere, selbst für den Fall des explizit typisierten Lambda.

Im Idealfall würde Eclipse hier anhalten und Unklarheiten melden. Leider enthält die Implementierung der Überlastungsauflösung zusätzlich zur Implementierung von JLS nicht trivialen Code. Nach meinem Verständnis muss dieser Code (der aus der Zeit stammt, als Java 5 neu war) beibehalten werden, um einige Lücken in JLS zu schließen.

Ich habe eingereicht https://bugs.eclipse.org/562538 , um dies zu verfolgen.

Unabhängig von diesem speziellen Fehler kann ich nur dringend von diesem Codestil abraten. Überladung ist gut für eine gute Anzahl von Überraschungen in Java, multipliziert mit Lambda-Typ-Inferenz. Die Komplexität ist im Verhältnis zum wahrgenommenen Gewinn ziemlich unverhältnismäßig.