Andrey,
Can you compile a full list of these risky methods, and elaborate on what
the risks are?
Generally, CompletableFuture is a much better option, because it's
standard. But we need to make sure it actually fits our needs and doesn't
do more harm than good.
-Val
On Thu, Mar 25, 2021 at 12:23 PM Alexei Scherbakov <
alexey.scherbak...@gmail.com> wrote:
> I think both options are fine, but personally lean toward
> CompletableFuture.
>
> чт, 25 мар. 2021 г. в 17:56, Atri Sharma <a...@apache.org>:
>
> > I would suggest using CompletableFuture -- I don't see a need for a
> custom
> > interface that is unique to us.
> >
> > It also allows a lower barrier for new contributors for understanding
> > existing code
> >
> > On Thu, 25 Mar 2021, 20:18 Andrey Mashenkov, <andrey.mashen...@gmail.com
> >
> > wrote:
> >
> > > Hi Igniters,
> > >
> > > I'd like to start a discussion about replacing our custom IgniteFuture
> > > class with CompletableFuture - existed JDK class
> > > or rework it's implementation (like some other products done) to a
> > > composition of CompletionStage and Future interfaces.
> > > or maybe other option if you have any ideas. Do you?
> > >
> > > 1. The first approach pros and cons are
> > > + Well-known JDK class
> > > + Already implemented
> > > - It is a class, not an interface.
> > > - Expose some potentially harmful methods like "complete()".
> > >
> > > On the other side, it has copy() method to create defensive copy and
> > > minimalCompletionStage() to restrict harmful method usage.
> > > Thus, this look like an applicable solution, but we should be careful
> > > exposing internal future to the outside.
> > >
> > > 2. The second approach is to implement our own interface like the next
> > one:
> > >
> > > interface IgniteFuture<T> extends CompletableStage<T>, Future<T> {
> > > }
> > >
> > > Pros and cons are
> > > + Our interfaces/classes contracts will expose an interface rather than
> > > concrete implementation.
> > > + All methods are safe.
> > > - Some implementation is required.
> > > - CompletableStage has a method toCompletableFuture() and can be
> > converted
> > > to CompletableFuture. This should be supported.
> > >
> > > However, we still could wrap CompletableFuture and don't bother about
> > > creating a defensive copy.
> > >
> > >
> > > Other project experience:
> > > * Spotify uses CompletableFuture directly [1].
> > > * Redis goes the second approach [2]
> > > * Vertx explicitly extends CompletableFuture [3]. However, they have
> > custom
> > > future classes and a number of helpers that could be replaced with
> > > CompletableStage. Maybe it is just a legacy.'
> > >
> > > Any thoughts?
> > >
> > > [1]
> > >
> > >
> >
> https://spotify.github.io/completable-futures/apidocs/com/spotify/futures/ConcurrencyReducer.html
> > > [2]
> > >
> > >
> >
> https://lettuce.io/lettuce-4/release/api/com/lambdaworks/redis/RedisFuture.html
> > > [3]
> > >
> > >
> >
> https://javadoc.io/static/org.jspare.vertx/vertx-jspare/1.1.0-M03/org/jspare/vertx/concurrent/VertxCompletableFuture.html
> > > --
> > > Best regards,
> > > Andrey V. Mashenkov
> > >
> >
>
>
> --
>
> Best regards,
> Alexei Scherbakov
>
