(original) (raw)

On Wed, Dec 5, 2012 at 10:02 AM, Brian Goetz <brian.goetz@oracle.com> wrote:

3\. �Tolerate nulls. �This treat nulls as "just another value" and

I think there may be some confusion due to the way the word "tolerance" has morphed in recent years? �By "tolerate", we don't mean "all men hug and sing a song of unity", we mean "let's not have open violence in the streets." �Perhaps we should call this "barely tolerate." �As Doug said, the key casualty of this is modular reasoning about what will happen in various cases when there are nulls. �I view this as an acceptable cost, and one borne entirely by the null-lovers. �When we achieve a better world in which people don't put nulls in collections, it will become a purely theoretical concern.

hopes that

lambdas and downstream stages can deal.

The key is "hope". �We don't guarantee that all stages \*can\* deal, nor do we bend over backwards to accommodate.

For example, the semantics of findAny/First are (as currently written) pretty much incompatible with null-bearing streams. �The return type is Optional<T> where Optional can either represent the absence of value or a present non-null value. �So I think it is perfectly reasonble to say "if the stream contains nulls, this may throw NPE."

As exemplified by the continuing set of patches for the
continuing (and probably never-ending) list of cases noted
on recent lambda-dev posts.

For many of these, I'm perfectly willing to specify that behavior in the presence of nulls is simply unpredictable; we're not necessarily patching things because we think they're bugs, so much as we're still at the point where patching is very cheap.

"Using null here may void your warranty".