Streams

Remi Forax forax at univ-mlv.fr
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:
>
> list.stream().map(l -> 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 
benefit,
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:
>
> https://github.com/spullara/java-future-jdk8/blob/master/src/main/java/spullara/util/concurrent/Promise.java
>
> 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.

Sam,
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

Rémi



More information about the lambda-spec-observers mailing list