Primitive streams and optional (original) (raw)

Remi Forax forax at univ-mlv.fr
Wed Nov 28 07:59:49 PST 2012

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

More information about the lambda-libs-spec-observers mailing list