Comparators.reverseOrder issues

[Georgiy Rakov]

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.
>>
>> Georgiy.
>>
>> 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:
>>>>
>>>> http://hg.openjdk.java.net/lambda/lambda/jdk/rev/f6366de3394c
>>>>
>>>> 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 
>>> comparator
>>> 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 
> Comparator.
> 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.
>
> Rémi
Thanks for detailed answer very much,
yes I think it's way to go too.

Georgiy.
>
>>>
>>> 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
>>> interface,
>>> (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 
>>> interfaces.
>>>
>>>> Paul.
>>> Rémi
>>>
>>>> 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.
>>>
>