[concurrency-interest] CompletableFuture in Java 8

thurstonn thurston at nomagicsoftware.com
Fri Dec 5 13:16:00 EST 2014

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()?
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)

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.

More information about the Concurrency-interest mailing list