CompletableFuture.supply

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

CompletableFuture.supply

Pavel Rappo
Hi, given [1] I wonder if anyone thinks this could be a useful method to be
added to j.u.c.CompletableFuture:

    public static <U> CompletableFuture<U> supply(Supplier<U> supplier)

Just a completable future that is to be completed by one of those who claim its
result. Right now I simulate it like this:

    CompletableFuture.supply(supplier, Runnable::run)       (A)

or a less flexible way [2] like this:

    CompletableFuture.complete( supplier.get() )            (B)

My concern is that it's not very pretty. Also it is the only method which
missing its non-async counterpart (not that I have any kind of method-symmetry
OCD, but anyway).

-------------------------------------------------------------------------------
[1] http://cs.oswego.edu/pipermail/concurrency-interest/2015-January/013600.html
[2] In case "B" I'm starting (unconditionally and synchronously) a possibly
    heavy computation. Which may not be needed at all (e.g. theAcceptEither).
_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: CompletableFuture.supply

Kasper Nielsen-4
Hi Pavel,

This method has already been added in latest and will (most likely)  be included in Java 9. 
public static <U> CompletableFuture<U> supplyAsync(Supplier<U> supplier)


- Kasper

On Wed, Mar 11, 2015 at 5:11 PM, Pavel Rappo <[hidden email]> wrote:
Hi, given [1] I wonder if anyone thinks this could be a useful method to be
added to j.u.c.CompletableFuture:

    public static <U> CompletableFuture<U> supply(Supplier<U> supplier)

Just a completable future that is to be completed by one of those who claim its
result. Right now I simulate it like this:

    CompletableFuture.supply(supplier, Runnable::run)       (A)

or a less flexible way [2] like this:

    CompletableFuture.complete( supplier.get() )            (B)

My concern is that it's not very pretty. Also it is the only method which
missing its non-async counterpart (not that I have any kind of method-symmetry
OCD, but anyway).

-------------------------------------------------------------------------------
[1] http://cs.oswego.edu/pipermail/concurrency-interest/2015-January/013600.html
[2] In case "B" I'm starting (unconditionally and synchronously) a possibly
    heavy computation. Which may not be needed at all (e.g. theAcceptEither).
_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest


_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: CompletableFuture.supply

Pavel Rappo
Hey Kasper,

You're right. CompletableFuture.supplyAsync is there. What I'm talking about is
a _synchronous_ version of "supplying" functionality.
Unfortunately I've made a typo in my previous mail, so this might have confused
you. It should have been written like this:

    CompletableFuture.supplyAsync(supplier, Runnable::run)  (A)

instead of:

    CompletableFuture.supply(supplier, Runnable::run)       (A)

Any chance this clarifies my previous email?


On Wed, Mar 11, 2015 at 5:02 PM, Kasper Nielsen <[hidden email]> wrote:

> Hi Pavel,
>
> This method has already been added in latest and will (most likely)  be
> included in Java 9.
> public static <U> CompletableFuture<U> supplyAsync(Supplier<U> supplier)
>
> see
> http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/main/java/util/concurrent/CompletableFuture.java?revision=1.158&view=markup
>
> - Kasper
>
> On Wed, Mar 11, 2015 at 5:11 PM, Pavel Rappo <[hidden email]> wrote:
>>
>> Hi, given [1] I wonder if anyone thinks this could be a useful method to
>> be
>> added to j.u.c.CompletableFuture:
>>
>>     public static <U> CompletableFuture<U> supply(Supplier<U> supplier)
>>
>> Just a completable future that is to be completed by one of those who
>> claim its
>> result. Right now I simulate it like this:
>>
>>     CompletableFuture.supply(supplier, Runnable::run)       (A)
>>
>> or a less flexible way [2] like this:
>>
>>     CompletableFuture.complete( supplier.get() )            (B)
>>
>> My concern is that it's not very pretty. Also it is the only method which
>> missing its non-async counterpart (not that I have any kind of
>> method-symmetry
>> OCD, but anyway).
>>
>>
>> -------------------------------------------------------------------------------
>> [1]
>> http://cs.oswego.edu/pipermail/concurrency-interest/2015-January/013600.html
>> [2] In case "B" I'm starting (unconditionally and synchronously) a
>> possibly
>>     heavy computation. Which may not be needed at all (e.g.
>> theAcceptEither).
>> _______________________________________________
>> Concurrency-interest mailing list
>> [hidden email]
>> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>
>
_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: CompletableFuture.supply

Doug Lea
In reply to this post by Pavel Rappo
On 03/11/2015 12:11 PM, Pavel Rappo wrote:

> Hi, given [1] I wonder if anyone thinks this could be a useful method to be
> added to j.u.c.CompletableFuture:
>
>      public static <U> CompletableFuture<U> supply(Supplier<U> supplier)
>
> Just a completable future that is to be completed by one of those who claim its
> result. Right now I simulate it like this:
>
>      CompletableFuture.supply(supplier, Runnable::run)       (A)
>
> or a less flexible way [2] like this:
>
>      CompletableFuture.complete( supplier.get() )            (B)

Or:
    CompletableFuture.completedFuture(supplier.get())

One reason for not defining non-async supply was that one of the
above would always be applicable. But if there's a missing use case,
please argue for adding this.

-Doug


>
> My concern is that it's not very pretty. Also it is the only method which
> missing its non-async counterpart (not that I have any kind of method-symmetry
> OCD, but anyway).
>
> -------------------------------------------------------------------------------
> [1] http://cs.oswego.edu/pipermail/concurrency-interest/2015-January/013600.html
> [2] In case "B" I'm starting (unconditionally and synchronously) a possibly
>      heavy computation. Which may not be needed at all (e.g. theAcceptEither).
> _______________________________________________
> Concurrency-interest mailing list
> [hidden email]
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: CompletableFuture.supply

Pavel Rappo
Doug, I don't think there's a missing use case. As you've said it could be done
with methods we already have. Though a similar argument can be applied to
existing methods. For instance `allOf` and `anyOf`. We could have written
something like this every time we needed their functionality [*]:

    public static CompletableFuture<Void> allOf(CompletableFuture<?>... cfs) {
        Objects.requireNonNull(cfs);
        if (cfs.length == 0) {
            return CompletableFuture.completedFuture(null);
        }
        CompletableFuture<Void> allOf;
        allOf = cfs[0].thenRunAsync(() -> {
        });
        for (int i = 1; i < cfs.length; i++) {
            allOf = allOf.runAfterBothAsync(cfs[i], () -> { });
        }
        return allOf;
    }

Agreed, this use case occurs much more frequently and the code to address it is
more error prone. Also implementing it internally in CompletableFuture gives you
a chance to make it more performant than the example above.

Probably you're right. Maybe there's no need for such a simple thing as
CompletableFuture.supply. So on rare occasions I need _synchronous_ supply/run
I will write:

        CompletableFuture.supplyAsync(supplier, Runnable::run);
and
        CompletableFuture.runAsync(command, Runnable::run);

accordingly. Thanks.

-------------------------------------------------------------------------------
[*] Just a sketch for illustrative purposes, may have nasty bugs

On Wed, Mar 11, 2015 at 11:23 PM, Doug Lea <[hidden email]> wrote:

> On 03/11/2015 12:11 PM, Pavel Rappo wrote:
>>
>> Hi, given [1] I wonder if anyone thinks this could be a useful method to
>> be
>> added to j.u.c.CompletableFuture:
>>
>>      public static <U> CompletableFuture<U> supply(Supplier<U> supplier)
>>
>> Just a completable future that is to be completed by one of those who
>> claim its
>> result. Right now I simulate it like this:
>>
>>      CompletableFuture.supply(supplier, Runnable::run)       (A)
>>
>> or a less flexible way [2] like this:
>>
>>      CompletableFuture.complete( supplier.get() )            (B)
>
>
> Or:
>    CompletableFuture.completedFuture(supplier.get())
>
> One reason for not defining non-async supply was that one of the
> above would always be applicable. But if there's a missing use case,
> please argue for adding this.
>
> -Doug
>
>
>>
>> My concern is that it's not very pretty. Also it is the only method which
>> missing its non-async counterpart (not that I have any kind of
>> method-symmetry
>> OCD, but anyway).
>>
>>
>> -------------------------------------------------------------------------------
>> [1]
>> http://cs.oswego.edu/pipermail/concurrency-interest/2015-January/013600.html
>> [2] In case "B" I'm starting (unconditionally and synchronously) a
>> possibly
>>      heavy computation. Which may not be needed at all (e.g.
>> theAcceptEither).
>> _______________________________________________
>> Concurrency-interest mailing list
>> [hidden email]
>> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>>
>
> _______________________________________________
> Concurrency-interest mailing list
> [hidden email]
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest