Comparator/Comparators API change proposal

[Michael Hixson]

Hi Henry,

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

  int result = Comparators
      .nullsFirst(c1)
      .thenComparing(c2)
      .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?

-Michael

On Mon, Jun 3, 2013 at 2:33 PM, Henry Jen <henry.jen at oracle.com> 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
>
> http://cr.openjdk.java.net/~henryjen/ccc/8009736.1/specdiff
>
> Thoughts?
>
> Cheers,
> Henry