[concurrency-interest] CompletableFuture in Java 8

Doug Lea dl at cs.oswego.edu
Fri Dec 5 09:41:05 EST 2014

On 12/04/2014 11:30 PM, Josh Humphries wrote:
> I'll elaborate on my thinking....

Thanks. It hadn't occurred to me that anyone would consider
CompletionStage.toCompletableFuture to be any less desirable
than Collection.toArray (which motivated toCompletableFuture).
Both provide an efficient base interoperation mechanism.
As mentioned, we considered other ways to do this, but all
seem worse except perhaps on their attitudinal impact,
which I hadn't considered. I'm not sure what we can or
should do about this now though.

> There is a spectrum. On one end (let's call it "simple"), you want a programming
> model that makes it easier to write correct code and that is easy to read,
> write, understand, and troubleshoot (at the extreme: all synchronous, all
> blocking flows -- very simple to understand

The goal of the "structure async" reactive approach (of which
CompletableFuture is one part) is to make these even simpler and
easier to use than traditional constructions, at least once
you get used to them. (Which seems plausible: Notice the success
of Node.js, based on impoverished forms of promises/futures
in JavaScript.)

As mentioned in other posts, development is still chaotic:
there are multiple frameworks with overlapping functionality,
and uncoordinated development of structured-async versions
of blocking components. Plus we face continuing challenges to
address resource problems when people mix blocking and
async components.


More information about the Concurrency-interest mailing list