Nulls

[Brian Goetz]

> The main downside is that findAny is forced to lie (reporting absent)
> if a null item matches predicate.

I'm not sure I'd describe throwing as "reporting absent", but I see the 
point -- we may make a distinction of "its not the stream throwing, its 
the optional", but users may not see the difference.  But, in any case, 
as downsides go (and there has to be one), this one doesn't seem as bad 
as most of the alternatives.

If users want a non-null result in cases like this, they can add a 
.filter(o -> o != null) and order is restored.  (The same way they'd 
deal with any null-hostile target and null-friendly stream; explicitly 
filter out the nulls.)  If we want to make this idiom prettier we can 
add Objects::isNull / Objects::isNonNull).

Giving the user the choice of filtering the nulls explicitly or not 
seems better than either implicitly filtering or implicitly throwing. 
(Yes, Option-bearing findXxx is implicitly throwing, which makes for a 
slightly more complex rule.)  In the happy case, it doesn't make a 
difference, but in the unhappy case, users are in full control.

> Unless you want to reconsider
> whether present Optionals can be null. Which no one seems to want to do.

Not me.