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

Tomas Mikula tomas.mikula at gmail.com
Tue Feb 11 17:50:05 EST 2014


On Tue, Feb 11, 2014 at 11:14 PM, Zhong Yu <zhong.j.yu at gmail.com> wrote:
> 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;

Thanks!

I was thinking of writing such an fxExecutor and didn't realize that
Executor was a SAM interface, so it's this easy!

Tomas

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