[concurrency-interest] map over j.u.c.CompletableFuture with strict threading semantics

Dimitar Georgiev dimitar.georgiev.bg at gmail.com
Fri Oct 20 11:32:46 EDT 2017

Thanks Viktor! I had not thought of it this way, and you are absolutely right.

I hope it is okay to expand the discussion a little bit and go a bit
off-topic from j.u.c. Viktor probably already sees where this is
going. Next is flatMap:

public static <A, B> CompletableFuture<B> flatMap(CompletableFuture<A>
future, Function<A, CompletableFuture<B>> f);

Semantics my app requires here: if the result of f() is completed on a
new threading context, I want subsequent map / flatMap operations to
use that context. If not (if the result of f() is pure, i.e. of the
form new CompletableFuture<>().complete(value)), continue in the same
threading context.

 Viktor, your remark leads me to think there is no sane way to achieve
this semantics with an eager future implementation such as
CompletableFuture. I would need something lazy which is a description,
creating the thing be referentially transparent, and
submission/execution be decoupled from creating the thing.

To finish the off-topic with the actual question:
- Does such a thing exist in the Java ecosystem at all? I know it does
in Scala, but I need a Java alternative.

P.S. I found a couple of months ago https://github.com/traneio/future.
A claim is made that the threading semantics are what I just
described, but it is an eager future. I will look into the
implementation in the coming days; I expect it to be something along
the "workaround" Viktor described. Myself, I don't feel I am smart
enough or have the testing and formal verification tools to go down
that path...

On 20 October 2017 at 17:52, Viktor Klang <viktor.klang at gmail.com> wrote:
> Hi Dimitar,
> In general this is not possible, nor desirable, since completion is likely
> to happen *before* a transformation is added.
> However, there is nothing technical which prevents you to create an
> implementation of CompletionStage which stores a reference to the Executor
> to be used, and runs transformations which are applied to it on that
> Executor unless some other Executor is specified.
> --
> Cheers,
> On Oct 20, 2017 09:41, "Dimitar Georgiev" <dimitar.georgiev.bg at gmail.com>
> wrote:
> Sorry if this has already been discussed.
> I need to implement the following function:
> public static <A, B> CompletableFuture<B> map(CompletableFuture<A>
> upstream, Function<A, B> f);
> It's pretty apparent what the function does. However, it has the
> requirement that f() be always executed in the thread where upstream
> is completed. (That is, if upstream is completed non-exceptionally,
> since if it was not, f will not be called so there is no threading
> semantics concerning f)
> Is this possible with j.u.c.CompletableFuture?
> Regards, Dimitar
> _______________________________________________
> 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