[concurrency-interest] CompletableFuture in Java 8

√iktor Ҡlang viktor.klang at gmail.com
Mon Dec 1 10:58:11 EST 2014

On Mon, Dec 1, 2014 at 2:58 PM, Doug Lea <dl at cs.oswego.edu> wrote:

> 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.

I guess it depends whether one wants that feature overridable (one can go
from CompletionStage to CompletableFuture with the combinators)

> 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:
>   https://www.youtube.com/watch?v=2y5Pv4yN0b0&app=desktop
> 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.

Hmmm, if only there was some kind of successor-like language to Java... :-)

> -Doug
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20141201/a82a35e2/attachment.html>

More information about the Concurrency-interest mailing list