Nulls

[Joe Bowbeer]

On Fri, Sep 21, 2012 at 9:25 AM, Brian Goetz wrote:

> I think the "if we don't support it people won't adopt lambda" is way, way
> overstated.  Its a factor to consider, nothing more.
>
> But, the reality is that code where there are nulls in collections is
> still likely to blow *somewhere*.  Yes, it would be great if it blew where
> the null was inserted.  But that ship has sailed.  What we're discussing
> now is:
>  - should we check nulls when the element flows into the stream?
>  - should we check nulls at the other end, like forEach/into/toArray?
>  - should we stick our fingers in our ears and say "la la la can't see
> those nulls la la la"?



I think there is a strong usability case for supporting nulls.  I see it
this way:

Q: How many Java methods return null?
A: Countless many, and there is no type-system in place to indicate when
they do or don't

Q: What will lamda users want to do?
A: Apply their methods and collect the results; perform parallel reduction,
stream them, etc.

We will either need to force these lambda users to create Optional-like
adapters for all of their sources of null in the world, or we will need to
support the most common use cases without throwing exceptions.  I don't
like the first option for lambda initiates because it presents them with a
hurdle right away.

I'm undecided whether Optional is of any use in the bigger design effort.
 I'm certain they won't be as useful as they are in Scala, because the
absence of Optional doesn't mean anything in Java -- whereas the absence in
Scala can mean no NPE.  In any event, Optional should be subservient to the
bigger design effort.

Joe