[concurrency-interest] CompletableFuture in Java 8

Doug Lea dl at cs.oswego.edu
Mon Dec 1 08:58:35 EST 2014

On 12/01/2014 05:07 AM, √iktor Ҡlang wrote:

>     Viktor recapped the good arguments for not extending Future. But
>     we still needed a standard means for interoperable implementations to
>     extract values. Method toCompletableFuture() is the simplest way to get
>     this effect by anyCompletableFuture developer (usually a one-liner),
>     and is marked as optional in case they don't care about interoperability.
> I agree from a discoverability-perspective, even if I'd rather had seen a
> CompletableFuture.fromStage(stage) method as to keep the generic part oblivious
> of the implementation.

Right, except that this method must be virtual and overridden
by a CompletionStage implementation. If interfaces could have
"protected" methods, it might have been a slightly better
indication that this method is solely for the sake of
interoperability and shouldn't ordinarily be called by
framework users. This is a common API design problem:
Sometimes saying "shouldn't call" is the best you can do
when you ideally want to restrict calls to special contexts.

This is the model we had in mind with CompletionStage:
It doesn't include any way of getting or setting or waiting for
results, so is a preferable return type for most
user-level methods in layered frameworks. But it still
has the toCompletableFuture escape hatch that must
be discouraged by policy vs type-checkers. Doing
more than this requires wrapping/delegation to
distinguish internal vs external usages in a statically
enforceable way. If people are going to do this frequently,
we ought to make it easier, by creating AbstractCompletionStage.

> Perhaps this is the perfect time for a j.u.c2? With all we've learned the past
> 10-15 years :-)

This is almost never possible in core language/libraries.
See Brian Goetz's recent talk:

But we can/do add new better stuff that we encourage people to use
instead of old stuff when it becomes less useful as the world changes.


More information about the Concurrency-interest mailing list