Sorting streams containing nulls

[Remi Forax]

[private]

On 11/29/2012 04:44 PM, Brian Goetz wrote:
> At a minimum, the comparator you provide to the sort would have to be
> explicitly written to handle nulls, since most comparators immediately
> dereference their arguments.
>
> It would be nice if NPEs were not thrown from *within* the library in
> this case.  But we're not ready to commit to that in the spec yet.  So I
> would put the current behavior wrt nulls in sorting as "unfortunate" but
> not erroneous behavior.  We may tighten this later, but for now, I think
> this is allowable.

NPE in middle of JDK code is a bug not a feature.
we have to mask/unmask null in the implementation.

Rémi

>
> On 11/29/2012 10:20 AM, Georgiy Rakov wrote:
>> Hello,
>>
>> could you please provide more explicit answer.
>>
>> Details:
>> You've said that nulls are allowed so imagine we have a stream
>> containing some nulls. Than we want to sort it.
>>
>> Here I see following contradiction.
>>    From the one hand if nulls are allowed they should be treated properly.
>> It means when the sequence is sorted nulls should honestly be passed to
>> supplied comparator and moved to its place in accordance with the result
>> returned by comparator. This could not be done if NPE is thrown by
>> implementation.
>>    From another hand you've said that nulls should be filtered out
>> otherwise NPE is thrown.
>>
>> So could you please answer explicitly:
>> - if this situation is considered as a bug and is going to be fixed; by
>> "this situation" I mean the fact that NPE is thrown while sorting the
>> stream containing nulls as described in my original message below;
>> - or whether this situation is considered as expected behavior.
>>
>> Thanks,
>> Georgiy.
>>
>> On 13.11.2012 21:15, Howard Lovatt wrote:
>>> The expert groups has decided to go with allowing nulls and using an Option type and as a result if you don't filter out nulls [.filter(x->x!=null)] then you will get NPE. My preference would be for nulls to be banned, like ConcurrentHashMap does. But it is hardly the end of the world, just annoying that you have to put filters in if in doubt.
>>>
>>> Sent from my iPad
>>>
>>> On 13/11/2012, at 4:08 PM, Georgiy Rakov<georgiy.rakov at oracle.com>  wrote:
>>>
>>>> On 07.11.2012 18:08, Sergey Kuksenko wrote:
>>>>> But it is sorted stream.
>>>>> How should we compare null with other values?
>>>> The supplied comparator could treat nulls in a special way. There are
>>>> some ways to do it for instance:
>>>> - comparator could consider null as the lowest value;
>>>> - when sorting integers comparator could consider null being equal to
>>>> some integer value for instance 5;
>>>>
>>>> Georgiy
>>>>
>>>>> On 11/07/2012 05:43 PM, Remi Forax wrote:
>>>>>> On 11/07/2012 02:30 PM, Brian Goetz wrote:
>>>>>>> The exact specification is not yet written, but we are not expecting stream implementations or operations to do anything special with nulls.  This means nulls may be passed to lambdas or inserted into collections that do not support them, resulting in NPE.
>>>>>> so it's an implementation bug ?
>>>>>> All Queue don't accept null so either null need to be masked/unmasked or
>>>>>> the implementation has to be changed.
>>>>>>
>>>>>> Rémi
>>>>>>
>>>>>>> On Nov 7, 2012, at 5:22 AM, Georgiy Rakov wrote:
>>>>>>>
>>>>>>>> Hello.
>>>>>>>>
>>>>>>>> When we make sorted(...).iterator() on Stream instance containing one
>>>>>>>> ore more nulls we receive NPE. The example of stack trace is below:
>>>>>>>>
>>>>>>>>         java.lang.NullPointerException
>>>>>>>>              at java.util.PriorityQueue.offer(PriorityQueue.java:320)
>>>>>>>>              at java.util.PriorityQueue.add(PriorityQueue.java:306)
>>>>>>>>              at java.util.streams.ops.SortedOp.iterator(SortedOp.java:105)
>>>>>>>>              at java.util.streams.ops.SortedOp.wrapIterator(SortedOp.java:97)
>>>>>>>>              at
>>>>>>>>         java.util.streams.AbstractPipeline.iterator(AbstractPipeline.java:329)
>>>>>>>>              ...
>>>>>>>>
>>>>>>>> Could you please tell if it is considered as expected behavior or it's
>>>>>>>> going to be fixed somehow.
>>>>>>>>
>>>>>>>> Georgiy.
>>>>>>>>