Doug Lea dl at
Fri Sep 14 04:54:24 PDT 2012

(CCing lambda-libs-spec-experts, which seems better for follow-ups).

On 09/14/12 03:13, Remi Forax wrote:
> On 09/14/2012 07:23 AM, Sam Pullara wrote:
>> Here are some issues that I find with the current Streams implementation:
>> 1) Collection is not a Stream. This means that whenever you use
>> collections and want to use some of the great new features you have to
>> first convert it to a stream:
>> -> parseInt(l)).into(new ArrayList<>())
>> I find this unnecessary. Collection could implement Stream and the
>> default methods could do the conversion for me, probably by calling
>> .stream() as above.
> I fuly agree, it will be convenient to have such delegation mechanism.

There's some tension between convenience and sanity here :-)
I'll let Brian walk through the decision space...

> Is there a document somewhere that explain the pro and cons of using Optional ?
> Currently I see it as a way to add a level of indirection with no real benefit,

I don't think there is a document, but there has been a lot of discussion
about it  here and there over the years. I think they mainly amount to
two technical problems, plus at least one style/usage issue:

1. Some collections allow null elements, which means that you cannot
unambiguously use null in its otherwise only reasonable sense of "there's
nothing there".

2. If/when some of these APIs are extended to primitives, there is
no value to return in the case of nothing there. The alternative
to Optional is to return boxed types, which some people would prefer
not to do.

3. Some people like the idea of using Optional to allow more fluent APIs.
As in
   x = s.findFirst().or(valueIfEmpty)
   if ((x = s.findFirst()) == null) x = valueIfEmpty;
Some people are happy to create an object for the sake of
being able to do this. Although sometimes less happy when they
realize that Optionalism then starts propagating through their
designs, leading to Set<Optional<T>>'s and so on.

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.

>> 3) I really, really believe that we should have something around
>> Future like I have prototyped here:

Right. FutureValue/Promise/whatever is on our todo list for JDK8
(see JEP 155). One of the many little snags that have held it back
so far is getting past related issues like Numeric (see my post
on this).


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