Primitive streams and optional (original) (raw)

Doug Lea dl at cs.oswego.edu
Wed Dec 5 03:41:48 PST 2012

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

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