Sorting streams containing nulls

[Roland Tepp]

I think something should be provided that would address this issue in a
standard and easily understandable manner.

Google guava has Ordering.nullsFirst() and Ordering.nullsLast() methods for
building such comparators.
I think lambda should have something similar.

2012/11/29 Brian Goetz <brian.goetz at oracle.com>

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


-- 
Roland