Primitive streams and optional

[Remi Forax]

On 12/05/2012 12:41 PM, Doug Lea wrote:
> 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.

The issue discussed in recent lambda-dev posts is how to pivot from a 
code that use null to say there is no value because null was not 
supported (so #1) to a code that use a constant NO_VALUE because now 
null is a supported value (so #3). If #2 was chosen, the code had to 
changed too.

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

If we can go back in time and disallow null for all collections, we will 
live in a better world, but that not the case.

BTW, the policy used by j.u.c is not the good one too. The best policy 
should be, never uses null.
I'm pretty sure that because j.u.c collections use null to tag entry 
that should be removed and because the VM aggressively optimizes value 
that was never null before, code that triggers de-optimization the first 
time you remove an element from a concurrent collection should exist.

>
> -Doug

Rémi