Comparator.reversed（）はラムダを使用してコンパイルしません

いくつかのUserオブジェクトを含むリストがあり、リストを並べ替えようとしていますが、メソッド参照を使用した場合にのみ機能します。ラムダ式を使用すると、コンパイラによってエラーが発生します。

List<User> userList = Arrays.asList(u1, u2, u3);
userList.sort(Comparator.comparing(u -> u.getName())); // works
userList.sort(Comparator.comparing(User::getName).reversed()); // works
userList.sort(Comparator.comparing(u -> u.getName()).reversed()); // Compiler error

エラー：

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

これは、コンパイラの型推論メカニズムの弱点です。uラムダのの型を推測するには、ラムダのターゲット型を確立する必要があります。これは次のように行われます。userList.sort()型の引数が必要ですComparator<User>。最初の行でComparator.comparing()は、を返す必要がありますComparator<User>。これは、引数を取るがComparator.comparing()必要であるFunctionことを意味しますUser。したがって、最初の行のラムダではu、タイプである必要がありUser、すべてが機能します。

2行目と3行目では、への呼び出しの存在によってターゲットのタイピングが中断されていますreversed()。理由はよくわかりません。レシーバと戻り値の型はどちらもそうなので、ターゲットの型をレシーバに伝播する必要reversed()があるComparator<T>ように見えますが、そうではありません。（私が言ったように、それは弱点です。）

2行目のメソッドリファレンスは、このギャップを埋める追加の型情報を提供します。コンパイラ推論がので、この情報は、第三の線に存在しないuことがObject失敗した（最後の推論フォールバック）。

もちろん、メソッド参照を使用できる場合は、それを実行すれば機能します。場合によっては、メソッド参照を使用できないことがあります。たとえば、追加のパラメーターを渡したい場合は、ラムダ式を使用する必要があります。その場合は、ラムダに明示的なパラメータータイプを指定します。

userList.sort(Comparator.comparing((User u) -> u.getName()).reversed());

将来のリリースでこのケースをカバーするようにコンパイラーを拡張できる可能性があります。

2番目の引数として2つの引数Comparator.comparingを使用することにより、この制限を回避できComparator.reverseOrder()ます。

users.sort(comparing(User::getName, reverseOrder()));