David M. Lloyd david.lloyd at
Fri Sep 14 06:15:59 PDT 2012

On 09/14/2012 07:51 AM, Tim Peierls wrote:
> On Fri, Sep 14, 2012 at 8:30 AM, Remi Forax <forax at
> <mailto:forax at>> wrote:
>         It's hard to win here. One of the many reasons that we
>         are supplying parallel bulk ops for ConcurrentHashMap that
>         fall outside the main stream framework is that issue #1 does
>         not arise (CHM disallows null keys and values), which
>         streamlines many design issues.
>     There is in my opinion a better design,
>        x = s.findFirst(valueIfEmpty);
> The trouble with that is that I often want to do something different
> depending on whether I found anything, and it is not always easy (or
> even possible) to find a distinct value to use as a sentinel. Rather
> than write ad hoc things like this:
>      Result result = filteredResults.findFirst(NO_RESULT);
>      if (result != NO_RESULT) ... use result ...
> I prefer being able to write:
>      Optional<Result> result = filteredResults.findFirst();
>      if (result.isPresent()) ... use result.get() ...
> Note that this preference is less about fluency than preventing user
> errors. It's all too easy to omit the test in the first snippet above,
> but if you try to use result directly in the second snippet without
> testing it, you'll get a compile error.
> I am sensitive to the risk of API pollution by folks who become
> over-enamored of Optional, as Doug hints (e.g., Set<Optional<T>>), but
> the rewards outweigh the risks, IMHO.

I don't know - to me Optional<T> is Pair<A, B>'s brother.  Both are 
useful, in their way, but both have potential to massively stink up 
code.  I don't really believe the benefits are worth it - I mean the 
best improvement we get isn't an objective "it's faster" or "it allows 
more optimal code paths", it's purely a style thing and it does have a 
cost.  I don't like it; I think it's going to result in things like:


or worse.

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