Comparators.reverseOrder issues

[Remi Forax]

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

>>
>> 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.
>>