[concurrency-interest] CompletableFuture.supply

Pavel Rappo pavel.rappo at gmail.com
Thu Mar 12 07:56:35 EDT 2015


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 <dl at cs.oswego.edu> 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
>> 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