[concurrency-interest] No *Task counterpart of CompletableFuture?

Zhong Yu zhong.j.yu at gmail.com
Tue Feb 11 17:14:51 EST 2014


On Tue, Feb 11, 2014 at 3:53 PM, Tomas Mikula <tomas.mikula at gmail.com> wrote:
> That's a good question and, as a matter of fact, I'm not even calling
> any Future methods on the result. I think it's just because of my
> current setting where I have other means of synchronization than
> Future.get(), namely I'm using Platform.runLater() from JavaFX, like
> this:
>
> res.thenAccept(r -> {
>     Platform.runLater(() -> handle(r));
> });

A probably better pattern:

    res.thenAcceptAsync( this::handle, fxExecutor );

    static final Executor fxExecutor = Platform::runLater;

>
> I thought in other settings you would need to eventually call
> Future.get() to synchronize with the main thread of computation.
>
> Are you suggesting that
> a) I should probably never need to call Future.get(); or
> b) there's always CompletionStage.toCompletableFuture() (which I only
> discovered now, so yes, I probably don't need Future)?
>
> Regards,
> Tomas
>
> On Tue, Feb 11, 2014 at 10:20 PM, √iktor Ҡlang <viktor.klang at gmail.com> wrote:
>>
>>
>>
>> On Tue, Feb 11, 2014 at 9:53 PM, Tomas Mikula <tomas.mikula at gmail.com>
>> wrote:
>>>
>>> On Tue, Feb 11, 2014 at 8:46 PM, Doug Lea <dl at cs.oswego.edu> wrote:
>>> > On 02/10/2014 07:24 PM, Tomas Mikula wrote:
>>> >>
>>> >> Hi,
>>> >>
>>> >> I really like the addition of the CompletionStage interface in 1.8.
>>> >> However, there is just one implementation of it and that is
>>> >> CompletableFuture. I am missing a task counterpart of it, i.e.
>>> >> something that is both a Future and a CompletionStage, but is
>>> >> completed by a computation (i.e. takes a Callable constructor argument
>>> >> or has a protected abstract compute() method).
>>> >
>>> >
>>> > There are instead (four) static methods that accept functions and return
>>> > a CompletableFuture that is complete after they run. For example
>>> > supplyAsync is pasted below. Do you have usages in mind where
>>> > you'd need something different?
>>> >
>>> >
>>> >     /**
>>> >      * Returns a new CompletableFuture that is asynchronously completed
>>> >      * by a task running in the given executor with the value obtained
>>> >      * by calling the given Supplier.
>>> >      *
>>> >      * @param supplier a function returning the value to be used
>>> >      * to complete the returned CompletableFuture
>>> >      * @param executor the executor to use for asynchronous execution
>>> >      * @param <U> the function's return type
>>> >      * @return the new CompletableFuture
>>> >      */
>>> >     public static <U> CompletableFuture<U> supplyAsync(Supplier<U>
>>> > supplier,
>>> >                                                        Executor
>>> > executor)
>>> >
>>>
>>> Thanks, Doug,
>>>
>>> turns out my research was too shallow. This is all I need to get the job
>>> done.
>>>
>>> There's just one minor wrinkle that I can live with. I am designing an
>>> asynchronous interface whose method should return something that is
>>> both a Future and a CompletionStage, but not necessarily a
>>> CompletableFuture, i.e. without the complete* methods. In other words,
>>> the interface should return something that completes on its own and
>>> thus doesn't need the complete* methods. I don't want the client of
>>> the interface to be able to call the complete* methods.
>>>
>>> I can accomplish this with
>>>
>>> interface Foo<T> {
>>>     <U, F extends CompletionStage<U> & Future<U>> F foo(Function<T, U> f);
>>> }
>>>
>>> which is slightly more verbose than (imaginary)
>>>
>>> interface Foo<T> {
>>>     <U> CompletionFuture<U> foo(Function<T, U> f);
>>> }
>>>
>>> where CompletionFuture is defined as suggested before:
>>>
>>> interface CompletionFuture<T> extends Future<T>, CompletionStage<T> {}
>>
>>
>> May I ask why it needs to implement Future?
>>
>>>
>>>
>>> Regards,
>>> Tomas
>>>
>>> >
>>> >>
>>> >> I imagine a hierarchy like this:
>>> >>
>>> >> interface CompletionFuture<T> extends Future<T>, CompletionStage<T> {}
>>> >>
>>> >> class CompletableFuture<T> implements CompletionFuture<T> {...}
>>> >>
>>> >> class CompletionFutureTask<T> implements CompletionFuture<T> {
>>> >>      public CompletionFutureTask(Callable<T> callable) {...}
>>> >>      // or
>>> >>      protected abstract T compute();
>>> >> }
>>> >>
>>> >>
>>> >> Is there a reason why this is missing? Is there a plan to add this?
>>> >>
>>> >> Thanks,
>>> >> Tomas
>>> >> _______________________________________________
>>> >> Concurrency-interest mailing list
>>> >> Concurrency-interest at cs.oswego.edu
>>> >> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>>> >>
>>> >
>>> > _______________________________________________
>>> > Concurrency-interest mailing list
>>> > Concurrency-interest at cs.oswego.edu
>>> > http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>>> _______________________________________________
>>> Concurrency-interest mailing list
>>> Concurrency-interest at cs.oswego.edu
>>> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>>
>>
>>
>>
>> --
>> Cheers,
>>>>
>> ———————
>> Viktor Klang
>> Chief Architect - Typesafe
>>
>> Twitter: @viktorklang
>
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest



More information about the Concurrency-interest mailing list