[concurrency-interest] CompletableFuture in Java 8
viktor.klang at gmail.com
Mon Dec 8 10:37:16 EST 2014
Apologies for the late reply,
On Fri, Dec 5, 2014 at 7:16 PM, thurstonn <thurston at nomagicsoftware.com>
> 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
> 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
> 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:
> Sent from the JSR166 Concurrency mailing list archive at Nabble.com.
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Concurrency-interest