Primitive streams and optional

[Remi Forax]

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.
>>
>
> In case anyone was thinking that these have anything to do with
> efficiency, remember that JVMs are required to null-check each
> non-explicity-checked use of any reference anyway.
> So these three choices have similar costs.
>
> (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, if someone call any stream pipelines without sending null, 
it's ok. If there is just one codepath that sends one null through one 
pipeline, the user will pay a high tax once because the VM may have to 
deoptimize a lot of pipeline codes (not just the code of one pipeline).

Note that this may be not true in the future if the VM is able to 
specialize the code at the site of the call to the terminal op. In that 
case, send null will only affect one stream and not all of them.

To summarize, the javadoc of Stream should be clear that it's not 
because streams tolerate null that users should send null through them.
Also note that many implementations of collection/map exhibit the same 
issue if elements of collections or keys of map are once null.

>
> -Doug
>

Rémi