David M. Lloyd david.lloyd at
Fri Sep 21 11:38:52 PDT 2012

Not taking sides in the specific implementation debate, I just want to 
state that I don't think it really matters if there are "hurdles" to 
learning/using lambdas.  In fact it'd be better promote "better" 
practices if possible.  We don't have to *sell* this thing; rather it 
just has to be *good*.  I agree with Brian, and would further say: if 
it's "good" then the right people will use it when they're ready, and it 
will give them good results.  If it's "bad" (but, say, marginally easier 
to use as a result of the choices that make it "worse") we're just going 
to make the greater Java world an uglier place.

On 09/21/2012 01:04 PM, Joe Bowbeer wrote:
> 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


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