Comparators.comparing overloads

Sam Pullara spullara at
Sun Jul 21 14:25:39 PDT 2013

I agree that this seems pretty broken to me.


seem necessary to avoid this error:

java: reference to comparing is ambiguous
  both method <T>comparing(java.util.function.ToLongFunction<? super T>) in java.util.Comparator and method <T>comparing(java.util.function.ToDoubleFunction<? super T>) in java.util.Comparator match

Even stranger to me is that it doesn't even mention the correct one:

    public static <T> Comparator<T> comparing(ToIntFunction<? super T> keyExtractor) 

Good explanation for that?

Currently you need to write this code like:

        Comparator<String> comparator = Comparator.comparing((ToIntFunction<String>) String::length);

Which seems strange when I imagine this is a common case.


On Jul 21, 2013, at 2:16 PM, Richard Warburton <richard.warburton at> wrote:

> Hi,
> We only mangle the name for return types, not argument types.
> Thanks for the prompt reply.
> Things still seem a little messy in this situation though.  Perhaps I've
> missed something but we're talking about needing a cast for
> any keyExtractor function that returns a number.  That seems to be a fairly
> common scenario for a keyExtractor.  Suppose I want to sort Strings by
> length, and I want to write:
> Comparator<String> comparator = comparing(String::length);
> I'll get an error telling me that the "reference to comparing is
> ambiguous".  Now in fact I can't even hint to the compiler using a return
> type cast as with the following snippet:
> Comparator<String> comparator = comparing(str -> (int) str.length());
> I presume this is because a cast to int can auto-box to Integer which
> subtypes Object, so its still ambiguous between Function and ToIntFunction.
> Again, perhaps I've missed something here, but the way to get around this
> issue is by providing an explicit type for the keyExtractor function:
> ToIntFunction<String> lengthOfString = String::length;
> Comparator<String> comparator = comparing(lengthOfString);
> Which really does seem less elegant to me than having overloads with
> mangled names. As I say this isn't a weird corner case - numbers are an
> obvious thing to use as a comparator key.
> regards,
>  Dr. Richard Warburton
>  @RichardWarburto <>

More information about the lambda-dev mailing list