georgiy.rakov at oracle.com
Tue Oct 30 02:51:32 PDT 2012
On 29.10.2012 20:18, Remi Forax wrote:
> On 10/29/2012 04:15 PM, Georgiy Rakov wrote:
>> Rémi, thanks a lot for your answer,
>> my short comment is below.
>> On 29.10.2012 18:08, Remi Forax wrote:
>>> On 10/29/2012 12:10 PM, Paul Sandoz wrote:
>>>> Hi Georgiy,
>>>> Brian fixed 1) recently:
>>>> Although arguably that could break compatibility with existing
>>>> source and implementations that somehow worked around the CCE.
>>>> For 2) i am not sure what can be done, i think we are stuck with it.
>>> For 2), I think reverseOrder(null) should throw a NPE, if the
>>> is null.
>> Yes, the only counterargument I could see is the requirement of
>> Collections-like behavior.
> The code you need in collection like TreeSet by example is more to
> have a compare method
> that takes 3 arguments, the two objects to compare and an optional
> This method will use compareTo if the comparator is null or the
> comparator otherwise.
> BTW, having such generic method to do that is not a good idea because
> it will not allow the VM to optimize the code of a specific collection
> if a comparator is never null
> or always null because the runtime profile of all collections that may
> use a comparator will be shared.
> For reverseOrder, either you consider that a null comparator is
> meaning full and in that case
> reverseOrder(null) should just return null or you consider that
> meaning full null is
> a bad programming practice and throwing a NPE is a good way to be sure
> your users will
> agree with that idea :)
> In java.util.collection API, we start with, collections should support
> null idea in 1.2 and
> we change our mind in 1.5 so java.util.concurrent collections and
> Queue/Deque don't support null.
> So in my opinion, throwing a NPE is way to go.
Thanks for detailed answer very much,
yes I think it's way to go too.
>>> Note that now that we have default method, reverseOrder() should not be
>>> declared in Comparators
>>> but should be a default method of Comparator.
>>> Moreover when the compiler will accept to declare static methods in
>>> (I've not tested if it is already Ok) the classes Comparators,
>>> Predicates etc. should be removed
>>> and all the implementations should be moved in the corresponding
>>>> On Oct 29, 2012, at 11:31 AM, Georgiy
>>>> Rakov<georgiy.rakov at oracle.com> wrote:
>>>>> Hello colleagues,
>>>>> could you please give your thoughts and comments. Do you consider it
>>>>> worth taking into account?
>>>>> Thanks, Georgiy.
More information about the lambda-dev