[concurrency-interest] CompletableFuture in Java 8

√iktor Ҡlang viktor.klang at gmail.com
Mon Dec 8 10:37:16 EST 2014


Hi Thurstonn,

Apologies for the late reply,

On Fri, Dec 5, 2014 at 7:16 PM, thurstonn <thurston at nomagicsoftware.com>
wrote:

> Hello Viktor,
>
> Although this may seem a digression, I'm curious whether you object to
> something like Collectors#toList() in j.u.stream?
>
> Because this facilitates (I wouldn't say encourages) code like the
> following:
>
>
> List<T> l1 = . . .
> List<T> l2 = l1.stream().filter(...).collect(toList())
>
> List<T> l3 = l2.stream().map(...).collect(toList())
>
> for (T : l3)
>   do something
>
> Now, we can all agree that the code above is awful, even wrong, but is it's
> possibility (well, probably more than possibility - I've actually seen such
> code) enough to warrant the exclusion of Collectors.toList()?
>

At least that code doesn't impact liveness of the system. (well, you can
still OOME, but you can do that by allocating an array, so that's not
really the same)


> Of course the issue isn't exactly one of "encouraging blocking" (unless the
> streams were parallel) . . .
>
> I guess I think that "discouragement by difficulty" in API design more
> often
> than not leads to grief (which is not to say that I've never done it)
>

Do you have any example?


>
>
>
>
>
>
>
> --
> View this message in context:
> http://jsr166-concurrency.10961.n7.nabble.com/CompletableFuture-in-Java-8-tp11414p11578.html
> Sent from the JSR166 Concurrency mailing list archive at Nabble.com.
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>



-- 
Cheers,
√
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20141208/7a6b905d/attachment.html>


More information about the Concurrency-interest mailing list