brian.goetz at oracle.com
Wed Sep 26 13:00:54 PDT 2012
Trying again to categorize the choices and identify pros/cons...
Seems like there are four buckets here:
1. Ban nulls. This means that feeding nulls into a Stream MUST produce
2. Ignore nulls.
3. Tolerate nulls. Streams API takes no position on nulls, but may
well pass elements to less tolerant destinations (e.g., user-provided
lambdas, user-provided collections, Optional constructor.) Nulls may
cause NPEs in these cases.
4. Embrace nulls. Ensure that every operation can deal with nulls in a
well-defined manner. (This entails, for example, either dropping the
Optional-bearing methods or making present Optional deal with null.)
I think its safe to say that for each of these, there is some subset of
us who finds it undesirable.
Doug proposed (2) and (4). I proposed (3). Nearly everyone has some
sympathy for (1) but no one really wants to be that intolerant.
Attempted summary of pros/cons:
1 PRO: Predictable, simple
1 CON: Might be overly harsh, interferes with when user might actually
want to see nulls and can deal accordingly
2 PRO: Simple
2 CON: size() lies, interferes with optimizations, interferes with when
user might actually want to see nulls and can deal accordingly
3 PRO: Minimizes distortion on API, implementation in the null-free case
3 CON: more complex reasoning about what might happen, op behavior may
change subtly over time as implementation changes
4 PRO: Predictable
4 CON: sacrifices functionality/safety for sake of a corner case
More information about the lambda-libs-spec-experts