Comparator/Comparators API change proposal

Michael Hixson michael.hixson at
Mon Jun 3 17:07:51 PDT 2013

Hi Henry,

1. Does this code throw an NPE?  It's not clear from the docs.

  int result = Comparators
      .compare(null, null);

2. How did you decide which static methods should live on Comparator
versus Comparators?

3. There are a couple of awkward-sounding parts in the docs, e.g. "Try
to compare null with returned comparator will throw
NullPointerException."  Do you want me (and/or others) to suggest
concrete changes here, in this thread?


On Mon, Jun 3, 2013 at 2:33 PM, Henry Jen <henry.jen at> wrote:
> Hi,
> Static interface method support has being available for a while, it
> seems reasonable to move a couple methods from Comparators into Comparator.
> Also it is recommended to rename Function-variant comparing to according
> primitive type to eliminate ambiguity for lambda cases like following,
> <T,R> Comparator<T> comparing(Function<T,R> f);
> <T> Comparator<T> comparing(ToIntFunction<T> f);
> Comparator<String> c = comparing(s -> s.size());
> So here is what we are proposing,
> 1. Move all Comparators.comparing to Comparator.comparing
> 2. Rename various comparing methods to comparing, comparingInt,
> comparingLong and comparingDouble accordingly.
> 3. Same renaming apply to Comparator.thenComparing
> Other than that, we have
> 1. move Comparators.naturalOrder() and reverseOrder() to Comparator.
> Basically, static factory method should be in Comparator. Convenient
> helper/combinator methods such as byKey/byValue should be in Comparators.
> 2. rename Comparator.reverseOrder() default method to reverse(), it's
> simply reverse form of the comparator.
> 3. Add nullsFirst(Comparator cmp) and nullsLast(Comparator cmp) into
> Comparators as helper function to wrap up a comparator to be null-friendly.
> Specdiff can be found at
> Thoughts?
> Cheers,
> Henry

More information about the lambda-libs-spec-observers mailing list