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....@oracle.com> wrote: > Thanks Stuart for the review and correct link. > > Cheers, > Henry > > > On Aug 22, 2013, at 11:00 PM, Stuart Marks <stuart.ma...@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 >>> >
