Comparator/Comparators API change proposal
henry.jen at oracle.com
Tue Jun 4 15:22:12 PDT 2013
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
>>> .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
More information about the lambda-libs-spec-observers