kafka-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steven Aerts <steven.ae...@gmail.com>
Subject Re: [DISCUSS] KIP-218: Make KafkaFuture.Function java 8 lambda compatible
Date Sat, 02 Dec 2017 10:07:17 GMT
Hi Tom,

I just made changes to the proposal of KIP-218, to make everything more
backwards compatible as suggested by Collin.
For me it is now in a state where starts to become final.

I propose to wait a few days so everybody can take a look and open the
votes when I do not receive any major comments.

Does that sound ok for you?

https://cwiki.apache.org/confluence/display/KAFKA/KIP-218%3A+Make+KafkaFuture.Function+java+8+lambda+compatible

Thanks for your patience,


   Steven


Op vr 1 dec. 2017 om 11:55 schreef Tom Bentley <t.j.bentley@gmail.com>:

> Hi Steven,
>
> I'm particularly interested in seeing progress on this KIP as the work for
> KIP-183 needs a public version of BiConsumer. do you have any idea when the
> KIP might be ready for voting?
>
> Thanks,
>
> Tom
>
> On 10 November 2017 at 13:38, Steven Aerts <steven.aerts@gmail.com> wrote:
>
> > Collin, Ben,
> >
> > Thanks for the input.
> >
> > I will work out this proposa, so I get an idea on the impact.
> >
> > Do you think it is a good idea to line up the new method names with those
> > of CompletableFuture?
> >
> > Thanks,
> >
> >
> >    Steven
> >
> > Op vr 10 nov. 2017 om 12:12 schreef Ben Stopford <ben@confluent.io>:
> >
> > > Sounds like a good middle ground to me. What do you think Steven?
> > >
> > > On Mon, Nov 6, 2017 at 8:18 PM Colin McCabe <cmccabe@apache.org>
> wrote:
> > >
> > > > It would definitely be nice to use the jdk8 CompletableFuture.  I
> think
> > > > that's a bit of a separate discussion, though, since it has such
> heavy
> > > > compatibility implications.
> > > >
> > > > How about making KIP-218 backwards compatible?  As a starting point,
> > you
> > > > can change KafkaFuture#BiConsumer to an interface with no
> compatibility
> > > > implications, since there are currently no public functions exposed
> > that
> > > > use it.  That leaves KafkaFuture#Function, which is publicly used
> now.
> > > >
> > > > For the purposes of KIP-218, how about adding a new interface
> > > > FunctionInterface?  Then you can add a function like this:
> > > >
> > > > >  public abstract <R> KafkaFuture<R> thenApply(FunctionInterface<T,
> R>
> > > > function);
> > > >
> > > > And mark the older declaration as deprecated:
> > > >
> > > > >  @deprecated
> > > > >  public abstract <R> KafkaFuture<R> thenApply(Function<T,
R>
> > function);
> > > >
> > > > This is a 100% compatible way to make things nicer for java 8.
> > > >
> > > > cheers,
> > > > Colin
> > > >
> > > >
> > > > On Thu, Nov 2, 2017, at 10:38, Steven Aerts wrote:
> > > > > Hi Tom,
> > > > >
> > > > > Nice observation.
> > > > > I changed "Rejected Alternatives" section to "Other Alternatives",
> as
> > > > > I see myself as too much of an outsider to the kafka community to
> be
> > > > > able to decide without this discussion.
> > > > >
> > > > > I see two major factors to decide:
> > > > >  - how soon will KIP-118 (drop support of java 7) be implemented?
> > > > >  - for which reasons do we drop backwards compatibility for public
> > > > > interfaces marked as Evolving
> > > > >
> > > > > If KIP-118 which is scheduled for version 2.0.0 is going to be
> > > > > implemented soon, I agree with you that replacing KafkaFuture with
> > > > > CompletableFuture (or CompletionStage) is a preferable option.
> > > > > But as I am not familiar with the roadmap it is difficult to tell
> for
> > > me.
> > > > >
> > > > >
> > > > > Thanks,
> > > > >
> > > > >
> > > > >    Steven
> > > > >
> > > > >
> > > > > 2017-11-02 11:27 GMT+01:00 Tom Bentley <t.j.bentley@gmail.com>:
> > > > > > Hi Steven,
> > > > > >
> > > > > > I notice you've renamed the template's "Rejected Alternatives"
> > > section
> > > > to
> > > > > > "Other Alternatives", suggesting they're not rejected yet (or,
if
> > you
> > > > have
> > > > > > rejected them, I think you should give your reasons).
> > > > > >
> > > > > > Personally, I'd like to understand the arguments against simply
> > > > replacing
> > > > > > KafkaFuture with CompletableFuture in Kafka 2.0. In other words,
> if
> > > we
> > > > were
> > > > > > starting without needing to support Java 7 what would be the
> > > arguments
> > > > for
> > > > > > having our own KafkaFuture?
> > > > > >
> > > > > > Thanks,
> > > > > >
> > > > > > Tom
> > > > > >
> > > > > > On 1 November 2017 at 16:01, Ted Yu <yuzhihong@gmail.com>
wrote:
> > > > > >
> > > > > >> KAFKA-4423 is still open.
> > > > > >> When would Java 7 be dropped ?
> > > > > >>
> > > > > >> Thanks
> > > > > >>
> > > > > >> On Wed, Nov 1, 2017 at 8:56 AM, Ismael Juma <ismael@juma.me.uk>
> > > > wrote:
> > > > > >>
> > > > > >> > On Wed, Nov 1, 2017 at 3:51 PM, Ted Yu <yuzhihong@gmail.com>
> > > wrote:
> > > > > >> >
> > > > > >> > > bq. Wait for a kafka release which will not support
java 7
> > > anymore
> > > > > >> > >
> > > > > >> > > Do you want to raise a separate thread for the
above ?
> > > > > >> > >
> > > > > >> >
> > > > > >> > There is already a KIP for this so a separate thread
is not
> > > needed.
> > > > > >> >
> > > > > >> > Ismael
> > > > > >> >
> > > > > >>
> > > >
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message