Typinferenzkonflikte behindern umgekehrte Lambda-Komparatoren
Trotz ihrer weit verbreiteten Verwendung stellt die Comparator.reversed()-Methode von Java 8 in Kombination eine Kompilierungshürde dar mit Lambda-Ausdrücken, was zu folgendem Fehler führt:
com\java8\collectionapi\CollectionTest.java:35: error: cannot find symbol userList.sort(Comparator.comparing(u -> u.getName()).reversed()); ^ symbol: method getName() location: variable u of type Object 1 error
Dieses Problem ist auf eine Einschränkung im Typinferenzmechanismus des Compilers zurückzuführen. Wenn ein Lambda-Ausdruck mit Comparator.comparing() verwendet wird, ist ein Zieltyp erforderlich, um auf den Typ des Parameters zu schließen. Im ersten Beispiel wird aufgrund des folgenden Zieltyps festgestellt, dass u vom Typ „Benutzer“ ist:
Comparator.comparing() -> Function<User, User.getName()> -> User
Wenn jedoch reversed() eingeführt wird, wird der Zieltyp gestört und der Compiler kann nicht mehr Den richtigen Typ ableiten.
Um dieses Problem zu lösen, kann man auf die Verwendung von Methodenreferenzen zurückgreifen, die zusätzlichen Typ bereitstellen Informationen:
userList.sort(Comparator.comparing(User::getName).reversed());
Alternativ kann ein expliziter Parametertyp im Lambda angegeben werden:
userList.sort(Comparator.comparing((User u) -> u.getName()).reversed());
Es bleibt abzuwarten, ob zukünftige Compilererweiterungen diese Hürde bei der Typinferenz beheben werden.
Das obige ist der detaillierte Inhalt vonWarum verursacht „Comparator.reversed()' von Java 8 Typinferenzkonflikte mit Lambda-Ausdrücken?. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!