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