Would be nice if someone would prototype a new cache API and post the generated javadoc here. I think we all will benefit from reviewing it.
On Tue, Dec 20, 2016 at 12:17 PM, Vladimir Ozerov <voze...@gridgain.com> wrote: > Async API rework is mechanical addition of ~100 methods through copy-paste. > Should not take more than a day to implement and more than another day to > rework tests. > > On Tue, Dec 20, 2016 at 10:00 PM, Dmitriy Setrakyan <dsetrak...@apache.org > > > wrote: > > > How difficult is this change? Does not look like it can be done > overnight. > > > > On Tue, Dec 20, 2016 at 10:46 AM, Vladimir Ozerov <voze...@gridgain.com> > > wrote: > > > > > We already discussed this several months ago in other thread. > > > > > > "Async" methods is the most simple and straight API possible. .NET > world > > > goes this way all over their frameworks and nobody died. Hazelcast also > > > goes this way. Java goes this way (see CompletableFuture). This is > common > > > and well-known practice. The most impacted part of our API will be > cache, > > > +33 new methods. Though, I do not see how it can affect learning curve. > > > > > > Agree that we should deprecate AsyncSupport gradually and remove it no > > > earlier than in Apache Ignite 3.0. > > > > > > On Tue, Dec 20, 2016 at 9:31 PM, Dmitriy Setrakyan < > > dsetrak...@apache.org> > > > wrote: > > > > > > > On Tue, Dec 20, 2016 at 10:28 AM, Sergi Vladykin < > > > sergi.vlady...@gmail.com > > > > > > > > > wrote: > > > > > > > > > +1 For removing withAsync. It is a broken design. > > > > > > > > > > > > > Sergi, do you also want to add all the async methods to the main API > or > > > do > > > > you have some other design in mind? > > > > > > > > > >
