Remi Forax forax at
Fri Sep 14 00:13:54 PDT 2012

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.

> 2) Optional should implement more of the Stream API like flatMap and
> some others.
> Option<U> flatMap(Mapper<T, ? extends Optional<U>>)
> I also hate that with Optional.none() often needs to be witnessed and
> not a big fan of using a constructor for Optional:
> return matcher.matches() ? new Optional<>(matcher) : Optional.<Matcher>empty();
> should really be something more like (using static imports):
> return matcher.matches() ? option(matcher) : none();

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 
the VM currently optimizes code that check a variable is null if the 
variable is never null,
so this kind of nullcheck are free. With Optional you add a level of 
indirection in any case
(null or not null) and you have an allocation if you're not lucky and 
the escape analysis doesn't work.

> 3) I really, really believe that we should have something around
> Future like I have prototyped here:
> Blocking to get the result of a Future is a bad code smell in my mind
> after using Promises for a long time at Twitter. This will be a great
> opportunity to get all the APIs in line with a much better way of
> handling asynchronous work that isn't CPU bound.

I fully agree, and think you should move this question to 
concurrency-interest mailing list
at least to have Doug comments on this idea.

> Sam


More information about the lambda-spec-experts mailing list