Primitive streams and optional

[Doug Lea]

On 11/29/12 13:00, Remi Forax wrote:
> On 11/29/2012 04:42 PM, Doug Lea wrote:
>> On 11/28/12 10:59, Remi Forax wrote:
>>> On 11/28/2012 04:27 PM, Doug Lea wrote:
>>>> On 11/26/12 15:43, Brian Goetz wrote:
>>>>
>>>>> 1.  Ban nulls.  This is equivalent to adding
>>>>>     .tee(e -> { if (e == null) throw new NPE(); }
>>>>> between all stages of a pipeline.
>>>>>
>>>>> 2.  Ignore nulls.  This is what Doug is proposing, and is equivalent to adding
>>>>>     .filter(e -> e != null)
>>>>> between all stages of a pipeline.
>>>>>
>>>>> 3.  Tolerate nulls.  This treat nulls as "just another value" and hopes that
>>>>> lambdas and downstream stages can deal.
>>
>>>> (They do vary a little:  #3 will sometimes be the most expensive,
>>>> since the lack of a pre-null-check forces twistier code paths
>>>> to be generated later on first dereference of a field.)
>>>
>>> Yes, for #3, ...

And the costs for #3 increase each time you need to interpose the
null object pattern internally to transform #3 into a variant of #2.
As exemplified by the continuing set of patches for the
continuing (and probably never-ending) list of cases noted
on recent lambda-dev posts.

I was the first person to use null-masking in java.util
in an early contributed version of HashMap that remains
the basis of current version. There was/is no better way out.
But it adds runtime overhead and API complexity for ALL users
to cope with an inadvisable usage that makes no sense anyway.
This experience among others led to the non-nulls policy in j.u.c.

-Doug