这是编译器的类型推断机制的一个弱点。为了推断ulambda的类型，需要建立lambda的目标类型。这是如下完成的。
userList.sort()期待类型为的参数
Comparator<User>。在第一行中，
Comparator.comparing()需要返回
Comparator<User>。这意味着
Comparator.comparing()需要一个
Function带
User参数的a 。因此，在第一行的
lambda中，
u必须为
type User并且一切正常。
在第二行和第三行中，对的调用会干扰目标类型
reversed()。我不完全清楚为什么。接收器和的返回类型
reversed()都是
Comparator<T>如此，因此似乎应该将目标类型传播回接收器，但事实并非如此。（就像我说的那样，这是一个缺点。）
在第二行中，方法参考提供了填补此空白的其他类型信息。第三行缺少此信息，因此编译器推断u为
Object（失败的推断回退），这将失败。
显然，如果可以使用方法引用，则可以使用它。有时你不能使用方法引用，例如，如果你想传递附加参数，则必须使用lambda表达式。在这种情况下，你可以在lambda中提供一个明确的参数类型：
userList.sort(Comparator.comparing((User u) -> u.getName()).reversed());
在将来的发行版中，可能会增强编译器以涵盖这种情况。
