RFR: 8023528: Rename Comparator combinators to disambiguate overloading methods

[Zhong Yu]

I for one must express the concern that this is extremely ugly API. It
is another blow to the reputation of Java Language.

While we should not support overload with implicit lambda in general
cases, we should and can support it in the restricted case where all
overloading methods agree upon the lambda parameter types. This
restricted case happens to be the most common case where overload is
needed, e.g. Stream.map(), Comparator.comparing(). It is heartbreaking
to hear the decision of banning all overloads because of some bad
corner cases that won't likely happen in real code.

Zhong Yu


On Fri, Aug 23, 2013 at 11:11 AM, Henry Jen <henry.jen at oracle.com> wrote:
> Thanks Stuart for the review and correct link.
>
> Cheers,
> Henry
>
>
> On Aug 22, 2013, at 11:00 PM, Stuart Marks <stuart.marks at oracle.com> wrote:
>
>> Hi Henry,
>>
>> Changes look good. It's also good to see some now-extra casts and type witnesses removed. It somewhat makes up for the longer, non-overloaded method names.
>>
>> Note, corrected email thread[2] link:
>>
>> http://mail.openjdk.java.net/pipermail/lambda-libs-spec-experts/2013-August/002206.html
>>
>> s'marks
>>
>> On 8/22/13 8:21 PM, Henry Jen wrote:
>>> Hi,
>>>
>>> Please review a relative simple webrev[1] that basically simply renaming
>>> Comparator methods. The reason behind the renaming can be found at this
>>> email thread[2]. The specdiff is also available here[3].
>>>
>>> Cheers,
>>> Henry
>>>
>>> [1] http://cr.openjdk.java.net/~henryjen/ccc/8023528/0/webrev/
>>> [2]
>>> http://mail.openjdk.java.net/pipermail/lambda-libs-spec-expert/2013-August/002206.html
>>> [3]
>>> http://cr.openjdk.java.net/~henryjen/ccc/8023528/0/specdiff/overview-summary.html
>>>
>