Hi Viktor, Thanks for the reply.
It would not be possible for KafkaFuture to subclass CompletableFuture in a compatible way, as described (for CompletionStage, but the argument holds) in [1]. Kind regards, Tom [1]: https://github.com/apache/kafka/pull/9878#issuecomment-762955770 On Fri, Mar 19, 2021 at 2:57 PM Viktor Somogyi-Vass <viktorsomo...@gmail.com> wrote: > Hi Tom, > > Have you considered to directly subclass CompletableFuture? Can we do this? > Maybe a good addition to the alternatives. > > Thanks, > Viktor > > On Wed, Feb 24, 2021 at 10:13 AM Tom Bentley <tbent...@redhat.com> wrote: > > > If the next release is going to be Kafka 3.0, as seems to be the case, it > > would be a great time to decide whether and what we're doing with this > API. > > So I'd be grateful for any feedback people might have. > > > > Many thanks, > > > > Tom > > > > On Tue, Feb 2, 2021 at 10:40 AM Tom Bentley <tbent...@redhat.com> wrote: > > > > > I've previously discounted the possibility of an "Admin2" client, but > > > seeing the recent discussions on the thread for KIP-706, I wonder > whether > > > this current proposal in KIP-707 would benefit from a bit more > > > discussion... I think there are broadly two approaches to evolving the > > > Admin client API to use CompletionStage directly (rather than what's > > > currently proposed in KIP-707): > > > > > > The simpler option, from a development point of view, would be to > > > introduce an alternative/parallel set of classes for each of the > existing > > > result classes. E.g. ListTopicsOutcome which was the same as > > > ListTopicsResult, but using CompletionStage rather than KafkaFuture. > > Adding > > > methods to the existing Admin interface would require coming up with > > > synonym method names for every API call, and probably half of the API > > being > > > deprecated (if not immediately then in the long run). It would be > cleaner > > > to have a whole new interface, let's call it Manager, using the same > > method > > > names. The existing Admin client implementation would then wrap a > Manager > > > instance, and the existing Result classes could have a constructor > > > parameter of their corresponding Outcome instance which wrapped the > > > CompletionStages with KafkaFutures. The Options classes would be > > unchanged. > > > From a users point of view migrating to the new Manager client would > > mostly > > > be a matter of changing class names and adding a `.toCompletionStage()` > > to > > > those places where they were calling KafkaFuture.get()/getNow() (and > even > > > this could be avoided if we used CompletableFuture rather than > > > CompletionStage in the Outcome class APIs). In the long run Admin would > > be > > > removed and we'd be left with the minor annoyance of having a client > > called > > > Manager in a package called admin. > > > > > > The more involved version would do a similar refactoring, but within a > > > different package. If we stuck with the Admin and Result class names > the > > > users experience of migrating their codebase would be limited to > changing > > > import statements and the same additions of `.toCompletionStage()`. On > > the > > > implementation side it would force us to duplicate all the Options > > classes > > > and also have a way of converting old Options instances to their new > > > equivalents so that the old Admin implementation could delegate to the > > new > > > one. The main benefit of this approach seems to be the slightly easier > > > experience for people porting their code to the new client. > > > > > > In doing either of these much more significant refactorings there would > > > also be the opportunity to omit the current Admin API's deprecated > > methods > > > and classes from the new API. > > > > > > Do we think this is worth biting off in order to have more long term > > > consistency between the Admin, Producer and consumer APIs? > > > > > > Kind regards, > > > > > > Tom > > > > > > On Fri, Jan 22, 2021 at 3:02 PM Tom Bentley <tbent...@redhat.com> > wrote: > > > > > >> Hi, > > >> > > >> Following a recent discussion on a PR[1], I've written KIP-707 to > > >> establish what should be done to improve the API of KafkaFuture. > > >> If you have the time, your comments would be most welcome, as some of > > the > > >> rejected alternatives are not unreasonable. > > >> > > >> > > >> > > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-707%3A+The+future+of+KafkaFuture > > >> > > >> Many thanks, > > >> > > >> Tom > > >> > > >> [1]: https://github.com/apache/kafka/pull/9878 > > >> > > > > > >
