[concurrency-interest] CompletableFuture in Java 8
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
>> this effect by anyCompletableFuture developer (usually a one-liner),
>> and is marked as optional in case they don't care about
>> I agree from a discoverability-perspective, even if I'd rather had seen a
>> CompletableFuture.fromStage(stage) method as to keep the generic part
>> 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
>> 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.
Hmmm, if only there was some kind of successor-like language to Java... :-)
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Concurrency-interest