Comparator/Comparators API change proposal

[Henry Jen]

On 06/04/2013 02:22 AM, Paul Sandoz wrote:
> 
> 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 consider naturalOrderKeys() as a better version of
byKey(Comparator.naturalOrder()), thus leave it in Comparators.

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

There are only two methods not returning Comparator in Comparators, they
are lesserOf and greaterOf, which some suggested can be Comparator
default method as min and max.

This is a trade-off, we don't want too many static or default method in
an interface. Personally, I don't mind to leave everything in Comparators.

Perhaps remove nautralOrderKeys and naturalOrderValues is a good
alternative such that combinator in Comparators and factory-method in
Comparator?

Cheers,
Henry