Comparator/Comparators API change proposal

Paul Sandoz paul.sandoz at oracle.com
Tue Jun 4 02:22:26 PDT 2013


On Jun 4, 2013, at 3:13 AM, Henry Jen <henry.jen at oracle.com> wrote:

> On Jun 3, 2013, at 5:07 PM, Michael Hixson <michael.hixson at gmail.com> wrote:
> 
>> 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);
>> 
> 
> It should return 0; otherwise, it's a bug.
> 
>> 2. How did you decide which static methods should live on Comparator
>> versus Comparators?
>> 
> 
> Good question, it can be confusing.
> 
> The (compromised) idea is that commonly-use constructor-like factory method will be in Comparator; Otherwise, in Comparators. Anything take a Comparator to return a comparator(i.e. combinator) should be in Comparators with the exception of comparing(Function, Comparator).
> 
> I would like to hear if there are better suggestions.
> 

It feels to me a somewhat artificial distinction, given that naturalOrder is present on Comparator but naturalOrderKeys is not.

I would be inclined to have all the static methods on Comparator and if required make Comparators package private for providing supporting artifacts.

Paul.


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