My only comment is that it seems to be a big rework and should not be addressed in this sprint. I also suggest that we look at CompletableFuture from JDK8: https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/CompletableFuture.html
D. On Tue, Feb 10, 2015 at 1:54 AM, Yakov Zhdanov <[email protected]> wrote: > Guys, I think that we should rework our future to make it more clean and > lightweight. > > 1. remove async notification - everyone can create listener that executes > in async manner > 2. we can remove context - it will not be used in future any more > 3. remove boolean fields that manage async settings > 4. remove validity check + externalizable > 5. remove listeners collection, but have 1 listener and chain them if > needed. I suspect in 99% of cases we have only 1 listener. > > Feel free to comment - https://issues.apache.org/jira/browse/IGNITE-216 > > -- > Yakov Zhdanov, Director R&D > *GridGain Systems* > www.gridgain.com > > 2015-02-10 3:52 GMT+03:00 Dmitriy Setrakyan <[email protected]>: > > > +1 > > > > On Mon, Feb 9, 2015 at 4:35 PM, Valentin Kulichenko < > > [email protected]> wrote: > > > > > Igniters, > > > > > > Anyone knows why GridFutureAdapter implements Externalizable? This is > > > useless from my point of view and error-prone, because it forces him to > > > have default constructor. It's invalid to use it directly in code, but > > for > > > some reason there are 84 (!!!) usages and I just caught an assertion > > > because of one of them. > > > > > > I think we should remove Externalizable from futures, remove default > > > constructor and revisit all wrong usages. > > > > > > If there are no objections, I will create a ticket. > > > > > > Thanks! > > > -- > > > Valentin > > > > > >
