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

√iktor Ҡlang viktor.klang at gmail.com
Tue Feb 11 16:20:19 EST 2014


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 <http://www.typesafe.com/>*

Twitter: @viktorklang
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20140211/bdd671e3/attachment.html>


More information about the Concurrency-interest mailing list