Relationship to CompositeFuture?

[aschrijver]

Hi @cescoffier

Nice project! I'll intend to try it out. Since you were also test-driving your microservices projects here, are you intending this to become a standard part of the Vert.x toolkit? If yes, what is the relationship to CompositeFuture? Is this intended to replace that?

On the any and all feature I recently had a discussion with @vietj with additional overloads that wait till all results are in. This same discussion can be applied to CompletableFuture I suppose.
I submitted an initial PR but ultimately we decided on a join method and predicate functions to model the behavior, which @vietj created.

See original issue: eclipse-vertx/vert.x#1430
And PR resulting from it: eclipse-vertx/vert.x#1567

[cescoffier]

So far there is no plan to integrate this project into Vert.x core, it can be used without any modification as a companion library. I started this project as a POC. It won't replace CompositeFuture as VertxCompletableFuture are not polyglot - and works only for Java.

You can create a VertxCompletableFuture from a Vert.x future, including CompositeFuture as they are Vert.x Future. I was thinking add a toFuture method to let a VertxCompletableFuture be wrapped as a Vert.x Future (I was also thinking implementing the Vert.x Future interface).

About all and any, all does not wait for all results to be received. As soon as it gets a failure (completedExceptionally) the handler is invoked. Same behavior for any I guess, but I didn't check. Adding a join composite operation make sense, however CompletableFuture have a join operation already. so the name would be confusing.

[aschrijver]

Thanks for your explanation.
Maybe this is a candidate for the commons module category I proposed in vert-x3/issues rather than a whole module in itself.

Regarding join and other such naming would be nice if there was some consistency amongst similarly purposed logic.
My concern is risk of getting a sprawl of more or less similar classes with overlapping features (not just futures but in general) dispersed troughout standard and community modules that may add power to Vert.x but at the cost of intuitiveness and simplicity. More a form of technical debt.

[bmsantos]

It would be great to have this package as part of the official Vert.x packages.

[manikantag]

Integrating with Vert.x will allows us to use https://github.com/electronicarts/ea-async

ea-async needs the methods to return variant of CompletableFuture: vert-x3/vertx-sync#10