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.ae...@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 <b...@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 <cmcc...@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.bent...@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 <yuzhih...@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 <ism...@juma.me.uk> > > > wrote: > > > > >> > > > > >> > On Wed, Nov 1, 2017 at 3:51 PM, Ted Yu <yuzhih...@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 > > > > >> > > > > > >> > > > > > >
