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

Tomas Mikula tomas.mikula at gmail.com
Tue Feb 11 15:53:57 EST 2014


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

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


More information about the Concurrency-interest mailing list