Comparator.reversed() does not compile using lambda

A deep dive to resolve the issue

Understanding the Comparator, lambdas, and the relationship with .reversed() is the starting point of resolving the issue.

Clearly defining lambda types

Defining types strictly ensures the compiler stays on track:

strings.sort(Comparator.comparing((String a) -> a).reversed());


No more playing hide and seek with the compiler.

Leaning into method references

Method references get rid of ambiguity, making type context clear:

list.sort(Comparator.comparing(User::getName).reversed());


Method references doing the heavy lifting, as usual.

Future improvement for type inference

The limitations of type inference might change with subsequent Java updates. For the present, making your intentions clear to the compiler helps:

List<User> users = // ...
users.sort(Comparator.<User>comparing(u -> u.getName()).reversed());


Hey compiler, it's <User>, not an alien species.

Tackling type challenges head on

While dealing with Comparator.reversed(), a comprehensive understanding of type inference and lambda expressions ensures your code doesn't go downhill.

Alternative way for reverse order

.reversed() can be cheeky. An approach dodging type issues is:

list.sort(Collections.reverseOrder(Comparator.comparing(User::getName)));


Collections.reverseOrder() is the type-tangle-free alternative.

Discerning Object fallback

The compiler defaulting to Object on type resolution failure is a hint. Spoon-feed it with more type hints:

list.sort(Comparator.<User>comparing(User::getName).reversed());


The <User> here is spoon-feeding the compiler with the right type.