Comparator/Comparators API change proposal
michael.hixson at gmail.com
Mon Jun 3 17:07:51 PDT 2013
1. Does this code throw an NPE? It's not clear from the docs.
int result = Comparators
2. How did you decide which static methods should live on Comparator
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 oracle.com> wrote:
> 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
More information about the lambda-libs-spec-observers