Mailing-List: contact dev-help@ignite.incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@ignite.incubator.apache.org
MIME-Version: 1.0
In-Reply-To: 
 <CA+0=VoWu1LxoGfGMVbtnAh67m_gxEyzYKw6oDyXQ5WJkBkwPhw@mail.gmail.com>
References: 
 <CABuYRcpUdy_HmfcJid1Aonua7Gc7BrB=d30QEpyb-Wn7gXGHKw@mail.gmail.com>
	<CA+0=VoX7CQrR6fJ5ahP1ndZtiNucAAwjfJegSP0aQd-rByU85A@mail.gmail.com>
	<CAGcMBHgDi5xXtY7_usicyLNGmJ7X-f8_TF_TF3zKYRE9ef3qvw@mail.gmail.com>
	<CA+0=VoWu1LxoGfGMVbtnAh67m_gxEyzYKw6oDyXQ5WJkBkwPhw@mail.gmail.com>
Date: Thu, 19 Feb 2015 17:46:32 +0400
Message-ID: 
 <CAGcMBHhtGNEr08JB4foEUES05o7uR924um=jUnKxavTeDcKa+w@mail.gmail.com>
Subject: Re: Serializable futures?
From: Yakov Zhdanov <yzhdanov@apache.org>
To: dev@ignite.incubator.apache.org
Content-Type: multipart/alternative; boundary=e89a8f642fb4e5404c050f71290c

--e89a8f642fb4e5404c050f71290c
Content-Type: text/plain; charset=UTF-8

Guys,

I looked a bit closer to java8 future. It has pretty cool features, but I
suggest not to backport them. For now we have listenAsync() and chain()
methods and if anyone needs such rich functionality he can implement that.
We will definitely implement CompletableFuture as a part of java8
migration, but a bit later.

So, if there are no objections let's proceed with the issues (ticket
updated):

1. Rename listenAsync(lsnr) -> listen(lsnr)
1.1 Async listening may be implemented inside listener itself - handlong
logic will be submitted to some pool. Convenience adapters may be added.
1.2 Async chaining may be implemented in the same way.
1.3 Java8 returns futures from "listening" methods that get done when
listener completes. I don's think we should implement it now. Let's
postpone it.
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.

--Yakov

2015-02-10 13:57 GMT+03:00 Dmitriy Setrakyan <dsetrakyan@apache.org>:

> 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 <yzhdanov@gridgain.com>
> 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 <dsetrakyan@apache.org>:
> >
> > > +1
> > >
> > > On Mon, Feb 9, 2015 at 4:35 PM, Valentin Kulichenko <
> > > valentin.kulichenko@gmail.com> 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
> > > >
> > >
> >
>

--e89a8f642fb4e5404c050f71290c--