You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@kafka.apache.org by Andy Coates <an...@confluent.io> on 2019/06/04 16:17:06 UTC

[VOTE] KIP-476: Add Java AdminClient interface

Hi folks

As there's been no chatter on this KIP I'm assuming it's non-contentious,
(or just boring), hence I'd like to call a vote for KIP-476:

https://cwiki.apache.org/confluence/display/KAFKA/KIP-476%3A+Add+Java+AdminClient+Interface

Thanks,

Andy

Re: [VOTE] KIP-476: Add Java AdminClient interface

Posted by Thomas Becker <Th...@tivo.com>.

+1 non-binding

We've run into issues trying to decorate the AdminClient due it being an abstract class. Will be nice to have consistency with Producer/Consumer as well.

On Tue, 2019-06-04 at 17:17 +0100, Andy Coates wrote:

Hi folks


As there's been no chatter on this KIP I'm assuming it's non-contentious,

(or just boring), hence I'd like to call a vote for KIP-476:


https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FKAFKA%2FKIP-476%253A%2BAdd%2BJava%2BAdminClient%2BInterface&amp;data=02%7C01%7CThomas.Becker%40tivo.com%7Ccf5880cd9d684d0489db08d6e9082607%7Cd05b7c6912014c0db45d7f1dcc227e4d%7C1%7C0%7C636952618549124417&amp;sdata=pC75MuDwA%2FzBeiGtIPwJVIjclchXO9Q9g5Uz4mTTjZY%3D&amp;reserved=0


Thanks,


Andy


--
[cid:022b6797e938d93974764f5b6df045112e31ce5e.camel@tivo.com] Tommy Becker
Principal Engineer
Personalized Content Discovery
O +1 919.460.4747
tivo.com<http://www.tivo.com/>

________________________________

This email and any attachments may contain confidential and privileged material for the sole use of the intended recipient. Any review, copying, or distribution of this email (or any attachments) by others is prohibited. If you are not the intended recipient, please contact the sender immediately and permanently delete this email and any attachments. No employee or agent of TiVo is authorized to conclude any binding agreement on behalf of TiVo by email. Binding agreements with TiVo may only be made by a signed written agreement.

Re: [VOTE] KIP-476: Add Java AdminClient interface

Posted by Andy Coates <an...@confluent.io>.

With 3.0 not imminent I would prefer to make this change soon, rather than
later.

On Tue, 11 Jun 2019 at 21:46, Colin McCabe <cm...@apache.org> wrote:

> On Tue, Jun 11, 2019, at 12:12, Andy Coates wrote:
> > Thanks for the response Colin,
> >
> > > What specific benefits do we get from transitioning to using an
> interface
> > > rather than an abstract class?
> >
> > This is covered in the KLIP: "An AdminClient interface has several
> > advantages over an abstract base class, most notably allowing
> > multi-inheritance and the use of dynamic proxies"
>
> Hi Andy,
>
> I was not that familiar with dynamic proxies, which is why the advantages
> weren't clear to me.  I had a conversation offline with Ismael and he
> explained some of the background here.
>
> The JDK includes a java.lang.reflect.Proxy class which can be used to
> create dynamic proxies, but only for interfaces -- not for abstract
> classes.  This is just a limitation in the library, though-- there are
> other ways of creating a dynamic proxy, like using cglib, that work with
> abstract classes as well as with interfaces.  But using something like
> cglib involves taking an external dependency, which could be annoying.
>
> >
> > > If we are serious about doing this, would it be cleaner to just change
> > > AdminClient from an abstract class to an interface in Kafka 3.0?  It
> would
> > > break binary compatibility, but you have to break binary compatibility
> in
> > > any case to get what you want here (no abstract class).  And it would
> have
> > > the advantage of not creating a lot of churn in the codebase as people
> > > replaced "AdminClient" with "Admin" all over the place.  What do you
> think?
> >
> > How far off is Kafka 3.0? This is causing us pain right now on a regular
> > basis and, from Ryanne's email above we're not alone. I'm not against
> > making this a change in Kafka 3.0, but only if its imminent.
>
> I don't believe 3.0 is imminent.
>
> >
> > > On a related note, one problem I've seen is that people will subclass
> > > AdminClient for testing.  Then, every time Kafka adds a new API, we
> add a
> > > new abstract method to the base class, which breaks compilation for
> them.
> > > Their test classes would have been fine simply failing when the new
> API was
> > > called.  So perhaps one useful class would be a class that implements
> the
> > > AdminClient API, and throws UnimplementedException for every method.
> The
> > > test classes could subclass this method and never have to worry about
> new
> > > methods getting added again.
> >
> > This is similar to what KSQL does for the other Kafka client APIs, except
> > we use a dynamic proxy, rather than having to hand code the exception
> > throwing.
>
> There is some performance penalty for the dynamic proxy approach, but it
> certainly is simpler.
>
> With this context in mind, the change sounds reasonable to me.
>
> best,
> Colin
>
> >
> > > Another pattern I've seen is people wanting to implement a class which
> is
> > > similar to KafkaAdminClient in every way, except for the behavior of
> > > close().  Specifically, people want to implement reference counting in
> > > order to reuse AdminClient instances.  So they start by implementing
> > > essentially a delegating class, which just forwards every method to an
> > > underlying AdminClient instance.  But this has the same problem that it
> > > breaks every time the upstream project adds an API.  In order to
> support
> > > this, we could have an official DelegatingAdminClient base class that
> > > forwarded every method to an underlying AdminClient instance.  Then the
> > > client code could override the methods they needed, like close.
> >
> > Again, this would be trivial to implement using dynamic proxies. No need
> > for us to implement any `DelegatingAdminClient`. If this is an interface
> we
> > empower users to do this for themselves.
> >
> > best,
> > Colin
> >
> > On Mon, 10 Jun 2019 at 21:44, Colin McCabe <cm...@apache.org> wrote:
> >
> > > Hi Andy,
> > >
> > > This is a big change, and I don't think there has been a lot of
> discussion
> > > about the pros and cons.  What specific benefits do we get from
> > > transitioning to using an interface rather than an abstract class?
> > >
> > > If we are serious about doing this, would it be cleaner to just change
> > > AdminClient from an abstract class to an interface in Kafka 3.0?  It
> would
> > > break binary compatibility, but you have to break binary compatibility
> in
> > > any case to get what you want here (no abstract class).  And it would
> have
> > > the advantage of not creating a lot of churn in the codebase as people
> > > replaced "AdminClient" with "Admin" all over the place.  What do you
> think?
> > >
> > > On a related note, one problem I've seen is that people will subclass
> > > AdminClient for testing.  Then, every time Kafka adds a new API, we
> add a
> > > new abstract method to the base class, which breaks compilation for
> them.
> > > Their test classes would have been fine simply failing when the new
> API was
> > > called.  So perhaps one useful class would be a class that implements
> the
> > > AdminClient API, and throws UnimplementedException for every method.
> The
> > > test classes could subclass this method and never have to worry about
> new
> > > methods getting added again.
> > >
> > > Another pattern I've seen is people wanting to implement a class which
> is
> > > similar to KafkaAdminClient in every way, except for the behavior of
> > > close().  Specifically, people want to implement reference counting in
> > > order to reuse AdminClient instances.  So they start by implementing
> > > essentially a delegating class, which just forwards every method to an
> > > underlying AdminClient instance.  But this has the same problem that it
> > > breaks every time the upstream project adds an API.  In order to
> support
> > > this, we could have an official DelegatingAdminClient base class that
> > > forwarded every method to an underlying AdminClient instance.  Then the
> > > client code could override the methods they needed, like close.
> > >
> > > best,
> > > Colin
> > >
> > >
> > > On Tue, Jun 4, 2019, at 09:17, Andy Coates wrote:
> > > > Hi folks
> > > >
> > > > As there's been no chatter on this KIP I'm assuming it's
> non-contentious,
> > > > (or just boring), hence I'd like to call a vote for KIP-476:
> > > >
> > > >
> > >
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-476%3A+Add+Java+AdminClient+Interface
> > > >
> > > > Thanks,
> > > >
> > > > Andy
> > > >
> > >
> >
>

Re: [VOTE] KIP-476: Add Java AdminClient interface

Posted by Andy Coates <an...@confluent.io>.

Thanks Great.

Do that mean you're a +1?

On Tue, 11 Jun 2019 at 21:46, Colin McCabe <cm...@apache.org> wrote:

> On Tue, Jun 11, 2019, at 12:12, Andy Coates wrote:
> > Thanks for the response Colin,
> >
> > > What specific benefits do we get from transitioning to using an
> interface
> > > rather than an abstract class?
> >
> > This is covered in the KLIP: "An AdminClient interface has several
> > advantages over an abstract base class, most notably allowing
> > multi-inheritance and the use of dynamic proxies"
>
> Hi Andy,
>
> I was not that familiar with dynamic proxies, which is why the advantages
> weren't clear to me.  I had a conversation offline with Ismael and he
> explained some of the background here.
>
> The JDK includes a java.lang.reflect.Proxy class which can be used to
> create dynamic proxies, but only for interfaces -- not for abstract
> classes.  This is just a limitation in the library, though-- there are
> other ways of creating a dynamic proxy, like using cglib, that work with
> abstract classes as well as with interfaces.  But using something like
> cglib involves taking an external dependency, which could be annoying.
>
> >
> > > If we are serious about doing this, would it be cleaner to just change
> > > AdminClient from an abstract class to an interface in Kafka 3.0?  It
> would
> > > break binary compatibility, but you have to break binary compatibility
> in
> > > any case to get what you want here (no abstract class).  And it would
> have
> > > the advantage of not creating a lot of churn in the codebase as people
> > > replaced "AdminClient" with "Admin" all over the place.  What do you
> think?
> >
> > How far off is Kafka 3.0? This is causing us pain right now on a regular
> > basis and, from Ryanne's email above we're not alone. I'm not against
> > making this a change in Kafka 3.0, but only if its imminent.
>
> I don't believe 3.0 is imminent.
>
> >
> > > On a related note, one problem I've seen is that people will subclass
> > > AdminClient for testing.  Then, every time Kafka adds a new API, we
> add a
> > > new abstract method to the base class, which breaks compilation for
> them.
> > > Their test classes would have been fine simply failing when the new
> API was
> > > called.  So perhaps one useful class would be a class that implements
> the
> > > AdminClient API, and throws UnimplementedException for every method.
> The
> > > test classes could subclass this method and never have to worry about
> new
> > > methods getting added again.
> >
> > This is similar to what KSQL does for the other Kafka client APIs, except
> > we use a dynamic proxy, rather than having to hand code the exception
> > throwing.
>
> There is some performance penalty for the dynamic proxy approach, but it
> certainly is simpler.
>
> With this context in mind, the change sounds reasonable to me.
>
> best,
> Colin
>
> >
> > > Another pattern I've seen is people wanting to implement a class which
> is
> > > similar to KafkaAdminClient in every way, except for the behavior of
> > > close().  Specifically, people want to implement reference counting in
> > > order to reuse AdminClient instances.  So they start by implementing
> > > essentially a delegating class, which just forwards every method to an
> > > underlying AdminClient instance.  But this has the same problem that it
> > > breaks every time the upstream project adds an API.  In order to
> support
> > > this, we could have an official DelegatingAdminClient base class that
> > > forwarded every method to an underlying AdminClient instance.  Then the
> > > client code could override the methods they needed, like close.
> >
> > Again, this would be trivial to implement using dynamic proxies. No need
> > for us to implement any `DelegatingAdminClient`. If this is an interface
> we
> > empower users to do this for themselves.
> >
> > best,
> > Colin
> >
> > On Mon, 10 Jun 2019 at 21:44, Colin McCabe <cm...@apache.org> wrote:
> >
> > > Hi Andy,
> > >
> > > This is a big change, and I don't think there has been a lot of
> discussion
> > > about the pros and cons.  What specific benefits do we get from
> > > transitioning to using an interface rather than an abstract class?
> > >
> > > If we are serious about doing this, would it be cleaner to just change
> > > AdminClient from an abstract class to an interface in Kafka 3.0?  It
> would
> > > break binary compatibility, but you have to break binary compatibility
> in
> > > any case to get what you want here (no abstract class).  And it would
> have
> > > the advantage of not creating a lot of churn in the codebase as people
> > > replaced "AdminClient" with "Admin" all over the place.  What do you
> think?
> > >
> > > On a related note, one problem I've seen is that people will subclass
> > > AdminClient for testing.  Then, every time Kafka adds a new API, we
> add a
> > > new abstract method to the base class, which breaks compilation for
> them.
> > > Their test classes would have been fine simply failing when the new
> API was
> > > called.  So perhaps one useful class would be a class that implements
> the
> > > AdminClient API, and throws UnimplementedException for every method.
> The
> > > test classes could subclass this method and never have to worry about
> new
> > > methods getting added again.
> > >
> > > Another pattern I've seen is people wanting to implement a class which
> is
> > > similar to KafkaAdminClient in every way, except for the behavior of
> > > close().  Specifically, people want to implement reference counting in
> > > order to reuse AdminClient instances.  So they start by implementing
> > > essentially a delegating class, which just forwards every method to an
> > > underlying AdminClient instance.  But this has the same problem that it
> > > breaks every time the upstream project adds an API.  In order to
> support
> > > this, we could have an official DelegatingAdminClient base class that
> > > forwarded every method to an underlying AdminClient instance.  Then the
> > > client code could override the methods they needed, like close.
> > >
> > > best,
> > > Colin
> > >
> > >
> > > On Tue, Jun 4, 2019, at 09:17, Andy Coates wrote:
> > > > Hi folks
> > > >
> > > > As there's been no chatter on this KIP I'm assuming it's
> non-contentious,
> > > > (or just boring), hence I'd like to call a vote for KIP-476:
> > > >
> > > >
> > >
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-476%3A+Add+Java+AdminClient+Interface
> > > >
> > > > Thanks,
> > > >
> > > > Andy
> > > >
> > >
> >
>

Re: [VOTE] KIP-476: Add Java AdminClient interface

Posted by Colin McCabe <cm...@apache.org>.

On Tue, Jun 11, 2019, at 12:12, Andy Coates wrote:
> Thanks for the response Colin,
> 
> > What specific benefits do we get from transitioning to using an interface
> > rather than an abstract class?
> 
> This is covered in the KLIP: "An AdminClient interface has several
> advantages over an abstract base class, most notably allowing
> multi-inheritance and the use of dynamic proxies"

Hi Andy,

I was not that familiar with dynamic proxies, which is why the advantages weren't clear to me.  I had a conversation offline with Ismael and he explained some of the background here.

The JDK includes a java.lang.reflect.Proxy class which can be used to create dynamic proxies, but only for interfaces -- not for abstract classes.  This is just a limitation in the library, though-- there are other ways of creating a dynamic proxy, like using cglib, that work with abstract classes as well as with interfaces.  But using something like cglib involves taking an external dependency, which could be annoying.

> 
> > If we are serious about doing this, would it be cleaner to just change
> > AdminClient from an abstract class to an interface in Kafka 3.0?  It would
> > break binary compatibility, but you have to break binary compatibility in
> > any case to get what you want here (no abstract class).  And it would have
> > the advantage of not creating a lot of churn in the codebase as people
> > replaced "AdminClient" with "Admin" all over the place.  What do you think?
> 
> How far off is Kafka 3.0? This is causing us pain right now on a regular
> basis and, from Ryanne's email above we're not alone. I'm not against
> making this a change in Kafka 3.0, but only if its imminent.

I don't believe 3.0 is imminent.

> 
> > On a related note, one problem I've seen is that people will subclass
> > AdminClient for testing.  Then, every time Kafka adds a new API, we add a
> > new abstract method to the base class, which breaks compilation for them.
> > Their test classes would have been fine simply failing when the new API was
> > called.  So perhaps one useful class would be a class that implements the
> > AdminClient API, and throws UnimplementedException for every method.  The
> > test classes could subclass this method and never have to worry about new
> > methods getting added again.
> 
> This is similar to what KSQL does for the other Kafka client APIs, except
> we use a dynamic proxy, rather than having to hand code the exception
> throwing.

There is some performance penalty for the dynamic proxy approach, but it certainly is simpler.

With this context in mind, the change sounds reasonable to me.

best,
Colin

> 
> > Another pattern I've seen is people wanting to implement a class which is
> > similar to KafkaAdminClient in every way, except for the behavior of
> > close().  Specifically, people want to implement reference counting in
> > order to reuse AdminClient instances.  So they start by implementing
> > essentially a delegating class, which just forwards every method to an
> > underlying AdminClient instance.  But this has the same problem that it
> > breaks every time the upstream project adds an API.  In order to support
> > this, we could have an official DelegatingAdminClient base class that
> > forwarded every method to an underlying AdminClient instance.  Then the
> > client code could override the methods they needed, like close.
> 
> Again, this would be trivial to implement using dynamic proxies. No need
> for us to implement any `DelegatingAdminClient`. If this is an interface we
> empower users to do this for themselves.
> 
> best,
> Colin
> 
> On Mon, 10 Jun 2019 at 21:44, Colin McCabe <cm...@apache.org> wrote:
> 
> > Hi Andy,
> >
> > This is a big change, and I don't think there has been a lot of discussion
> > about the pros and cons.  What specific benefits do we get from
> > transitioning to using an interface rather than an abstract class?
> >
> > If we are serious about doing this, would it be cleaner to just change
> > AdminClient from an abstract class to an interface in Kafka 3.0?  It would
> > break binary compatibility, but you have to break binary compatibility in
> > any case to get what you want here (no abstract class).  And it would have
> > the advantage of not creating a lot of churn in the codebase as people
> > replaced "AdminClient" with "Admin" all over the place.  What do you think?
> >
> > On a related note, one problem I've seen is that people will subclass
> > AdminClient for testing.  Then, every time Kafka adds a new API, we add a
> > new abstract method to the base class, which breaks compilation for them.
> > Their test classes would have been fine simply failing when the new API was
> > called.  So perhaps one useful class would be a class that implements the
> > AdminClient API, and throws UnimplementedException for every method.  The
> > test classes could subclass this method and never have to worry about new
> > methods getting added again.
> >
> > Another pattern I've seen is people wanting to implement a class which is
> > similar to KafkaAdminClient in every way, except for the behavior of
> > close().  Specifically, people want to implement reference counting in
> > order to reuse AdminClient instances.  So they start by implementing
> > essentially a delegating class, which just forwards every method to an
> > underlying AdminClient instance.  But this has the same problem that it
> > breaks every time the upstream project adds an API.  In order to support
> > this, we could have an official DelegatingAdminClient base class that
> > forwarded every method to an underlying AdminClient instance.  Then the
> > client code could override the methods they needed, like close.
> >
> > best,
> > Colin
> >
> >
> > On Tue, Jun 4, 2019, at 09:17, Andy Coates wrote:
> > > Hi folks
> > >
> > > As there's been no chatter on this KIP I'm assuming it's non-contentious,
> > > (or just boring), hence I'd like to call a vote for KIP-476:
> > >
> > >
> > https://cwiki.apache.org/confluence/display/KAFKA/KIP-476%3A+Add+Java+AdminClient+Interface
> > >
> > > Thanks,
> > >
> > > Andy
> > >
> >
>

Re: [VOTE] KIP-476: Add Java AdminClient interface

Posted by Andy Coates <an...@confluent.io>.

Thanks for the response Colin,

> What specific benefits do we get from transitioning to using an interface
rather than an abstract class?

This is covered in the KLIP: "An AdminClient interface has several
advantages over an abstract base class, most notably allowing
multi-inheritance and the use of dynamic proxies"

> If we are serious about doing this, would it be cleaner to just change
AdminClient from an abstract class to an interface in Kafka 3.0?  It would
break binary compatibility, but you have to break binary compatibility in
any case to get what you want here (no abstract class).  And it would have
the advantage of not creating a lot of churn in the codebase as people
replaced "AdminClient" with "Admin" all over the place.  What do you think?

How far off is Kafka 3.0? This is causing us pain right now on a regular
basis and, from Ryanne's email above we're not alone. I'm not against
making this a change in Kafka 3.0, but only if its imminent.

> On a related note, one problem I've seen is that people will subclass
AdminClient for testing.  Then, every time Kafka adds a new API, we add a
new abstract method to the base class, which breaks compilation for them.
Their test classes would have been fine simply failing when the new API was
called.  So perhaps one useful class would be a class that implements the
AdminClient API, and throws UnimplementedException for every method.  The
test classes could subclass this method and never have to worry about new
methods getting added again.

This is similar to what KSQL does for the other Kafka client APIs, except
we use a dynamic proxy, rather than having to hand code the exception
throwing.

> Another pattern I've seen is people wanting to implement a class which is
similar to KafkaAdminClient in every way, except for the behavior of
close().  Specifically, people want to implement reference counting in
order to reuse AdminClient instances.  So they start by implementing
essentially a delegating class, which just forwards every method to an
underlying AdminClient instance.  But this has the same problem that it
breaks every time the upstream project adds an API.  In order to support
this, we could have an official DelegatingAdminClient base class that
forwarded every method to an underlying AdminClient instance.  Then the
client code could override the methods they needed, like close.

Again, this would be trivial to implement using dynamic proxies. No need
for us to implement any `DelegatingAdminClient`. If this is an interface we
empower users to do this for themselves.

best,
Colin

On Mon, 10 Jun 2019 at 21:44, Colin McCabe <cm...@apache.org> wrote:

> Hi Andy,
>
> This is a big change, and I don't think there has been a lot of discussion
> about the pros and cons.  What specific benefits do we get from
> transitioning to using an interface rather than an abstract class?
>
> If we are serious about doing this, would it be cleaner to just change
> AdminClient from an abstract class to an interface in Kafka 3.0?  It would
> break binary compatibility, but you have to break binary compatibility in
> any case to get what you want here (no abstract class).  And it would have
> the advantage of not creating a lot of churn in the codebase as people
> replaced "AdminClient" with "Admin" all over the place.  What do you think?
>
> On a related note, one problem I've seen is that people will subclass
> AdminClient for testing.  Then, every time Kafka adds a new API, we add a
> new abstract method to the base class, which breaks compilation for them.
> Their test classes would have been fine simply failing when the new API was
> called.  So perhaps one useful class would be a class that implements the
> AdminClient API, and throws UnimplementedException for every method.  The
> test classes could subclass this method and never have to worry about new
> methods getting added again.
>
> Another pattern I've seen is people wanting to implement a class which is
> similar to KafkaAdminClient in every way, except for the behavior of
> close().  Specifically, people want to implement reference counting in
> order to reuse AdminClient instances.  So they start by implementing
> essentially a delegating class, which just forwards every method to an
> underlying AdminClient instance.  But this has the same problem that it
> breaks every time the upstream project adds an API.  In order to support
> this, we could have an official DelegatingAdminClient base class that
> forwarded every method to an underlying AdminClient instance.  Then the
> client code could override the methods they needed, like close.
>
> best,
> Colin
>
>
> On Tue, Jun 4, 2019, at 09:17, Andy Coates wrote:
> > Hi folks
> >
> > As there's been no chatter on this KIP I'm assuming it's non-contentious,
> > (or just boring), hence I'd like to call a vote for KIP-476:
> >
> >
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-476%3A+Add+Java+AdminClient+Interface
> >
> > Thanks,
> >
> > Andy
> >
>

Re: [VOTE] KIP-476: Add Java AdminClient interface

Posted by Colin McCabe <cm...@apache.org>.

Hi Andy,

This is a big change, and I don't think there has been a lot of discussion about the pros and cons.  What specific benefits do we get from transitioning to using an interface rather than an abstract class?

If we are serious about doing this, would it be cleaner to just change AdminClient from an abstract class to an interface in Kafka 3.0?  It would break binary compatibility, but you have to break binary compatibility in any case to get what you want here (no abstract class).  And it would have the advantage of not creating a lot of churn in the codebase as people replaced "AdminClient" with "Admin" all over the place.  What do you think?

On a related note, one problem I've seen is that people will subclass AdminClient for testing.  Then, every time Kafka adds a new API, we add a new abstract method to the base class, which breaks compilation for them.  Their test classes would have been fine simply failing when the new API was called.  So perhaps one useful class would be a class that implements the AdminClient API, and throws UnimplementedException for every method.  The test classes could subclass this method and never have to worry about new methods getting added again.

Another pattern I've seen is people wanting to implement a class which is similar to KafkaAdminClient in every way, except for the behavior of close().  Specifically, people want to implement reference counting in order to reuse AdminClient instances.  So they start by implementing essentially a delegating class, which just forwards every method to an underlying AdminClient instance.  But this has the same problem that it breaks every time the upstream project adds an API.  In order to support this, we could have an official DelegatingAdminClient base class that forwarded every method to an underlying AdminClient instance.  Then the client code could override the methods they needed, like close.

best,
Colin

On Tue, Jun 4, 2019, at 09:17, Andy Coates wrote:
> Hi folks
> 
> As there's been no chatter on this KIP I'm assuming it's non-contentious,
> (or just boring), hence I'd like to call a vote for KIP-476:
> 
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-476%3A+Add+Java+AdminClient+Interface
> 
> Thanks,
> 
> Andy
>

Re: [VOTE] KIP-476: Add Java AdminClient interface

Posted by Andy Coates <an...@confluent.io>.

That makes a lot of sense.  OK, no deprecation.

On Fri, 21 Jun 2019 at 15:11, Ismael Juma <is...@juma.me.uk> wrote:

> This is even more reason not to deprecate immediately, there is very little
> maintenance cost for us. We should be mindful that many of our users (eg
> Spark, Flink, etc.) typically allow users to specify the kafka clients
> version and hence avoid using new classes/interfaces for some time. They
> would get a bunch of warnings they cannot do anything about apart from
> suppressing.
>
> Ismael
>
> On Fri, Jun 21, 2019 at 4:00 AM Andy Coates <an...@confluent.io> wrote:
>
> > Hi Ismael,
> >
> > I’m happy enough to not deprecate the existing `AdminClient` class as
> part
> > of this change.
> >
> > However, note that, the class will likely be empty, i.e. all methods and
> > implementations will be inherited from the interface:
> >
> > public abstract class AdminClient implements Admin {
> > }
> >
> > Not marking it as deprecated has the benefit that users won’t see any
> > deprecation warnings on the next release. Conversely, deprecating it will
> > mean we can choose to remove this, now pointless class, in the future if
> we
> > choose.
> >
> > That’s my thinking for deprecation, but as I’ve said I’m happy either
> way.
> >
> > Andy
> >
> > > On 18 Jun 2019, at 16:09, Ismael Juma <is...@juma.me.uk> wrote:
> > >
> > > I agree with Ryanne, I think we should avoid deprecating AdminClient
> and
> > > causing so much churn for users who don't actually care about this
> niche
> > > use case.
> > >
> > > Ismael
> > >
> > > On Tue, Jun 18, 2019 at 6:43 AM Andy Coates <an...@confluent.io> wrote:
> > >
> > >> Hi Ryanne,
> > >>
> > >> If we don't change the client code, then everywhere will still expect
> > >> subclasses of `AdminClient`, so the interface will be of no use, i.e.
> I
> > >> can't write a class that implements the new interface and pass it to
> the
> > >> client code.
> > >>
> > >> Thanks,
> > >>
> > >> Andy
> > >>
> > >> On Mon, 17 Jun 2019 at 19:01, Ryanne Dolan <ry...@gmail.com>
> > wrote:
> > >>
> > >>> Andy, while I agree that the new interface is useful, I'm not
> convinced
> > >>> adding an interface requires deprecating AdminClient and changing so
> > much
> > >>> client code. Why not just add the Admin interface, have AdminClient
> > >>> implement it, and have done?
> > >>>
> > >>> Ryanne
> > >>>
> > >>> On Mon, Jun 17, 2019 at 12:09 PM Andy Coates <an...@confluent.io>
> > wrote:
> > >>>
> > >>>> Hi all,
> > >>>>
> > >>>> I think I've addressed all concerns. Let me know if I've not.  Can I
> > >> call
> > >>>> another round of votes please?
> > >>>>
> > >>>> Thanks,
> > >>>>
> > >>>> Andy
> > >>>>
> > >>>> On Fri, 14 Jun 2019 at 04:55, Satish Duggana <
> > satish.duggana@gmail.com
> > >>>
> > >>>> wrote:
> > >>>>
> > >>>>> Hi Andy,
> > >>>>> Thanks for the KIP. This is a good change and it gives the user a
> > >>> better
> > >>>>> handle on Admin client usage. I agree with the proposal except the
> > >> new
> > >>>>> `Admin` interface having all the methods from `AdminClient`
> abstract
> > >>>> class.
> > >>>>> It should be kept clean having only the admin operations as methods
> > >>> from
> > >>>>> KafkaClient abstract class but not the factory methods as mentioned
> > >> in
> > >>>> the
> > >>>>> earlier mail.
> > >>>>>
> > >>>>> I know about dynamic proxies(which were widely used in RMI/EJB
> > >> world).
> > >>> I
> > >>>> am
> > >>>>> curious about the usecase using dynamic proxies with Admin client
> > >>>>> interface. Dynamic proxy can have performance penalty if it is used
> > >> in
> > >>>>> critical path. Is that the primary motivation for creating the KIP?
> > >>>>>
> > >>>>> Thanks,
> > >>>>> Satish.
> > >>>>>
> > >>>>> On Wed, Jun 12, 2019 at 8:43 PM Andy Coates <an...@confluent.io>
> > >> wrote:
> > >>>>>
> > >>>>>> I'm not married to that part.  That was only done to keep it more
> > >> or
> > >>>> less
> > >>>>>> inline with what's already there, (an abstract class that has a
> > >>> factory
> > >>>>>> method that returns a subclass.... sounds like the same
> > >> anti-pattern
> > >>>> ;))
> > >>>>>>
> > >>>>>> An alternative would to have an `AdminClients` utility class to
> > >>> create
> > >>>>> the
> > >>>>>> admin client.
> > >>>>>>
> > >>>>>> On Mon, 10 Jun 2019 at 19:31, Matthias J. Sax <
> > >> matthias@confluent.io
> > >>>>
> > >>>>>> wrote:
> > >>>>>>
> > >>>>>>> Hmmm...
> > >>>>>>>
> > >>>>>>> So the new interface, returns an instance of a class that
> > >>> implements
> > >>>>> the
> > >>>>>>> interface. This sounds a little bit like an anti-pattern?
> > >> Shouldn't
> > >>>>>>> interfaces actually not know anything about classes that
> > >> implement
> > >>>> the
> > >>>>>>> interface?
> > >>>>>>>
> > >>>>>>>
> > >>>>>>> -Matthias
> > >>>>>>>
> > >>>>>>> On 6/10/19 11:22 AM, Andy Coates wrote:
> > >>>>>>>> `AdminClient` would be deprecated purely because it would no
> > >>> longer
> > >>>>>> serve
> > >>>>>>>> any purpose and would be virtually empty, getting all of its
> > >>>>>>> implementation
> > >>>>>>>> from the new interfar. It would be nice to remove this from the
> > >>> API
> > >>>>> at
> > >>>>>>> the
> > >>>>>>>> next major version bump, hence the need to deprecate.
> > >>>>>>>>
> > >>>>>>>> `AdminClient.create()` would return what it does today, (so
> > >> not a
> > >>>>>>> breaking
> > >>>>>>>> change).
> > >>>>>>>>
> > >>>>>>>> On Tue, 4 Jun 2019 at 22:24, Ryanne Dolan <
> > >> ryannedolan@gmail.com
> > >>>>
> > >>>>>> wrote:
> > >>>>>>>>
> > >>>>>>>>>> The existing `AdminClient` will be marked as deprecated.
> > >>>>>>>>>
> > >>>>>>>>> What's the reasoning behind this? I'm fine with the other
> > >>> changes,
> > >>>>> but
> > >>>>>>>>> would prefer to keep the existing public API intact if it's
> > >> not
> > >>>>>> hurting
> > >>>>>>>>> anything.
> > >>>>>>>>>
> > >>>>>>>>> Also, what will AdminClient.create() return? Would it be a
> > >>>> breaking
> > >>>>>>> change?
> > >>>>>>>>>
> > >>>>>>>>> Ryanne
> > >>>>>>>>>
> > >>>>>>>>> On Tue, Jun 4, 2019, 11:17 AM Andy Coates <an...@confluent.io>
> > >>>>> wrote:
> > >>>>>>>>>
> > >>>>>>>>>> Hi folks
> > >>>>>>>>>>
> > >>>>>>>>>> As there's been no chatter on this KIP I'm assuming it's
> > >>>>>>> non-contentious,
> > >>>>>>>>>> (or just boring), hence I'd like to call a vote for KIP-476:
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>
> > >>>>>>
> > >>>>>
> > >>>>
> > >>>
> > >>
> >
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-476%3A+Add+Java+AdminClient+Interface
> > >>>>>>>>>>
> > >>>>>>>>>> Thanks,
> > >>>>>>>>>>
> > >>>>>>>>>> Andy
> > >>>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>>
> > >>>>>
> > >>>>
> > >>>
> > >>
> >
> >
>

Re: [VOTE] KIP-476: Add Java AdminClient interface

Posted by Colin McCabe <cm...@apache.org>.

+1 (binding).

C.

On Mon, Jun 24, 2019, at 08:10, Andy Coates wrote:
> Hi all,
> 
> KIP updated:
> - No deprecation
> - Factory method back onto Admin interface
> 
> I'd like to kick off another round of voting please.
> 
> Thanks,
> 
> Andy
> 
> On Mon, 24 Jun 2019 at 16:03, Andy Coates <an...@confluent.io> wrote:
> 
> > I agree Matthias.
> >
> > (In Scala, such factory methods are on a companion object. As Java doesn't
> > have the concept of a companion object, an equivalent would be a utility
> > class with a similar name...)
> >
> > However, I'll update the KIP to include the factory method on the
> > interface.
> >
> > On Fri, 21 Jun 2019 at 23:40, Matthias J. Sax <ma...@confluent.io>
> > wrote:
> >
> >> I still think, that an interface does not need to know anything about
> >> its implementation. But I am also fine if we add a factory method to the
> >> new interface if that is preferred by most people.
> >>
> >>
> >> -Matthias
> >>
> >> On 6/21/19 7:10 AM, Ismael Juma wrote:
> >> > This is even more reason not to deprecate immediately, there is very
> >> little
> >> > maintenance cost for us. We should be mindful that many of our users (eg
> >> > Spark, Flink, etc.) typically allow users to specify the kafka clients
> >> > version and hence avoid using new classes/interfaces for some time. They
> >> > would get a bunch of warnings they cannot do anything about apart from
> >> > suppressing.
> >> >
> >> > Ismael
> >> >
> >> > On Fri, Jun 21, 2019 at 4:00 AM Andy Coates <an...@confluent.io> wrote:
> >> >
> >> >> Hi Ismael,
> >> >>
> >> >> I’m happy enough to not deprecate the existing `AdminClient` class as
> >> part
> >> >> of this change.
> >> >>
> >> >> However, note that, the class will likely be empty, i.e. all methods
> >> and
> >> >> implementations will be inherited from the interface:
> >> >>
> >> >> public abstract class AdminClient implements Admin {
> >> >> }
> >> >>
> >> >> Not marking it as deprecated has the benefit that users won’t see any
> >> >> deprecation warnings on the next release. Conversely, deprecating it
> >> will
> >> >> mean we can choose to remove this, now pointless class, in the future
> >> if we
> >> >> choose.
> >> >>
> >> >> That’s my thinking for deprecation, but as I’ve said I’m happy either
> >> way.
> >> >>
> >> >> Andy
> >> >>
> >> >>> On 18 Jun 2019, at 16:09, Ismael Juma <is...@juma.me.uk> wrote:
> >> >>>
> >> >>> I agree with Ryanne, I think we should avoid deprecating AdminClient
> >> and
> >> >>> causing so much churn for users who don't actually care about this
> >> niche
> >> >>> use case.
> >> >>>
> >> >>> Ismael
> >> >>>
> >> >>> On Tue, Jun 18, 2019 at 6:43 AM Andy Coates <an...@confluent.io>
> >> wrote:
> >> >>>
> >> >>>> Hi Ryanne,
> >> >>>>
> >> >>>> If we don't change the client code, then everywhere will still expect
> >> >>>> subclasses of `AdminClient`, so the interface will be of no use,
> >> i.e. I
> >> >>>> can't write a class that implements the new interface and pass it to
> >> the
> >> >>>> client code.
> >> >>>>
> >> >>>> Thanks,
> >> >>>>
> >> >>>> Andy
> >> >>>>
> >> >>>> On Mon, 17 Jun 2019 at 19:01, Ryanne Dolan <ry...@gmail.com>
> >> >> wrote:
> >> >>>>
> >> >>>>> Andy, while I agree that the new interface is useful, I'm not
> >> convinced
> >> >>>>> adding an interface requires deprecating AdminClient and changing so
> >> >> much
> >> >>>>> client code. Why not just add the Admin interface, have AdminClient
> >> >>>>> implement it, and have done?
> >> >>>>>
> >> >>>>> Ryanne
> >> >>>>>
> >> >>>>> On Mon, Jun 17, 2019 at 12:09 PM Andy Coates <an...@confluent.io>
> >> >> wrote:
> >> >>>>>
> >> >>>>>> Hi all,
> >> >>>>>>
> >> >>>>>> I think I've addressed all concerns. Let me know if I've not.  Can
> >> I
> >> >>>> call
> >> >>>>>> another round of votes please?
> >> >>>>>>
> >> >>>>>> Thanks,
> >> >>>>>>
> >> >>>>>> Andy
> >> >>>>>>
> >> >>>>>> On Fri, 14 Jun 2019 at 04:55, Satish Duggana <
> >> >> satish.duggana@gmail.com
> >> >>>>>
> >> >>>>>> wrote:
> >> >>>>>>
> >> >>>>>>> Hi Andy,
> >> >>>>>>> Thanks for the KIP. This is a good change and it gives the user a
> >> >>>>> better
> >> >>>>>>> handle on Admin client usage. I agree with the proposal except the
> >> >>>> new
> >> >>>>>>> `Admin` interface having all the methods from `AdminClient`
> >> abstract
> >> >>>>>> class.
> >> >>>>>>> It should be kept clean having only the admin operations as
> >> methods
> >> >>>>> from
> >> >>>>>>> KafkaClient abstract class but not the factory methods as
> >> mentioned
> >> >>>> in
> >> >>>>>> the
> >> >>>>>>> earlier mail.
> >> >>>>>>>
> >> >>>>>>> I know about dynamic proxies(which were widely used in RMI/EJB
> >> >>>> world).
> >> >>>>> I
> >> >>>>>> am
> >> >>>>>>> curious about the usecase using dynamic proxies with Admin client
> >> >>>>>>> interface. Dynamic proxy can have performance penalty if it is
> >> used
> >> >>>> in
> >> >>>>>>> critical path. Is that the primary motivation for creating the
> >> KIP?
> >> >>>>>>>
> >> >>>>>>> Thanks,
> >> >>>>>>> Satish.
> >> >>>>>>>
> >> >>>>>>> On Wed, Jun 12, 2019 at 8:43 PM Andy Coates <an...@confluent.io>
> >> >>>> wrote:
> >> >>>>>>>
> >> >>>>>>>> I'm not married to that part.  That was only done to keep it more
> >> >>>> or
> >> >>>>>> less
> >> >>>>>>>> inline with what's already there, (an abstract class that has a
> >> >>>>> factory
> >> >>>>>>>> method that returns a subclass.... sounds like the same
> >> >>>> anti-pattern
> >> >>>>>> ;))
> >> >>>>>>>>
> >> >>>>>>>> An alternative would to have an `AdminClients` utility class to
> >> >>>>> create
> >> >>>>>>> the
> >> >>>>>>>> admin client.
> >> >>>>>>>>
> >> >>>>>>>> On Mon, 10 Jun 2019 at 19:31, Matthias J. Sax <
> >> >>>> matthias@confluent.io
> >> >>>>>>
> >> >>>>>>>> wrote:
> >> >>>>>>>>
> >> >>>>>>>>> Hmmm...
> >> >>>>>>>>>
> >> >>>>>>>>> So the new interface, returns an instance of a class that
> >> >>>>> implements
> >> >>>>>>> the
> >> >>>>>>>>> interface. This sounds a little bit like an anti-pattern?
> >> >>>> Shouldn't
> >> >>>>>>>>> interfaces actually not know anything about classes that
> >> >>>> implement
> >> >>>>>> the
> >> >>>>>>>>> interface?
> >> >>>>>>>>>
> >> >>>>>>>>>
> >> >>>>>>>>> -Matthias
> >> >>>>>>>>>
> >> >>>>>>>>> On 6/10/19 11:22 AM, Andy Coates wrote:
> >> >>>>>>>>>> `AdminClient` would be deprecated purely because it would no
> >> >>>>> longer
> >> >>>>>>>> serve
> >> >>>>>>>>>> any purpose and would be virtually empty, getting all of its
> >> >>>>>>>>> implementation
> >> >>>>>>>>>> from the new interfar. It would be nice to remove this from the
> >> >>>>> API
> >> >>>>>>> at
> >> >>>>>>>>> the
> >> >>>>>>>>>> next major version bump, hence the need to deprecate.
> >> >>>>>>>>>>
> >> >>>>>>>>>> `AdminClient.create()` would return what it does today, (so
> >> >>>> not a
> >> >>>>>>>>> breaking
> >> >>>>>>>>>> change).
> >> >>>>>>>>>>
> >> >>>>>>>>>> On Tue, 4 Jun 2019 at 22:24, Ryanne Dolan <
> >> >>>> ryannedolan@gmail.com
> >> >>>>>>
> >> >>>>>>>> wrote:
> >> >>>>>>>>>>
> >> >>>>>>>>>>>> The existing `AdminClient` will be marked as deprecated.
> >> >>>>>>>>>>>
> >> >>>>>>>>>>> What's the reasoning behind this? I'm fine with the other
> >> >>>>> changes,
> >> >>>>>>> but
> >> >>>>>>>>>>> would prefer to keep the existing public API intact if it's
> >> >>>> not
> >> >>>>>>>> hurting
> >> >>>>>>>>>>> anything.
> >> >>>>>>>>>>>
> >> >>>>>>>>>>> Also, what will AdminClient.create() return? Would it be a
> >> >>>>>> breaking
> >> >>>>>>>>> change?
> >> >>>>>>>>>>>
> >> >>>>>>>>>>> Ryanne
> >> >>>>>>>>>>>
> >> >>>>>>>>>>> On Tue, Jun 4, 2019, 11:17 AM Andy Coates <an...@confluent.io>
> >> >>>>>>> wrote:
> >> >>>>>>>>>>>
> >> >>>>>>>>>>>> Hi folks
> >> >>>>>>>>>>>>
> >> >>>>>>>>>>>> As there's been no chatter on this KIP I'm assuming it's
> >> >>>>>>>>> non-contentious,
> >> >>>>>>>>>>>> (or just boring), hence I'd like to call a vote for KIP-476:
> >> >>>>>>>>>>>>
> >> >>>>>>>>>>>>
> >> >>>>>>>>>>>>
> >> >>>>>>>>>
> >> >>>>>>>>
> >> >>>>>>>
> >> >>>>>>
> >> >>>>>
> >> >>>>
> >> >>
> >> https://cwiki.apache.org/confluence/display/KAFKA/KIP-476%3A+Add+Java+AdminClient+Interface
> >> >>>>>>>>>>>>
> >> >>>>>>>>>>>> Thanks,
> >> >>>>>>>>>>>>
> >> >>>>>>>>>>>> Andy
> >> >>>>>>>>>>>>
> >> >>>>>>>>>>>
> >> >>>>>>>>>>
> >> >>>>>>>>>
> >> >>>>>>>>>
> >> >>>>>>>>
> >> >>>>>>>
> >> >>>>>>
> >> >>>>>
> >> >>>>
> >> >>
> >> >>
> >> >
> >>
> >>
>

Re: [VOTE] KIP-476: Add Java AdminClient interface

Posted by Andy Coates <an...@confluent.io>.

Hi all,

KIP updated:
- No deprecation
- Factory method back onto Admin interface

I'd like to kick off another round of voting please.

Thanks,

Andy

On Mon, 24 Jun 2019 at 16:03, Andy Coates <an...@confluent.io> wrote:

> I agree Matthias.
>
> (In Scala, such factory methods are on a companion object. As Java doesn't
> have the concept of a companion object, an equivalent would be a utility
> class with a similar name...)
>
> However, I'll update the KIP to include the factory method on the
> interface.
>
> On Fri, 21 Jun 2019 at 23:40, Matthias J. Sax <ma...@confluent.io>
> wrote:
>
>> I still think, that an interface does not need to know anything about
>> its implementation. But I am also fine if we add a factory method to the
>> new interface if that is preferred by most people.
>>
>>
>> -Matthias
>>
>> On 6/21/19 7:10 AM, Ismael Juma wrote:
>> > This is even more reason not to deprecate immediately, there is very
>> little
>> > maintenance cost for us. We should be mindful that many of our users (eg
>> > Spark, Flink, etc.) typically allow users to specify the kafka clients
>> > version and hence avoid using new classes/interfaces for some time. They
>> > would get a bunch of warnings they cannot do anything about apart from
>> > suppressing.
>> >
>> > Ismael
>> >
>> > On Fri, Jun 21, 2019 at 4:00 AM Andy Coates <an...@confluent.io> wrote:
>> >
>> >> Hi Ismael,
>> >>
>> >> I’m happy enough to not deprecate the existing `AdminClient` class as
>> part
>> >> of this change.
>> >>
>> >> However, note that, the class will likely be empty, i.e. all methods
>> and
>> >> implementations will be inherited from the interface:
>> >>
>> >> public abstract class AdminClient implements Admin {
>> >> }
>> >>
>> >> Not marking it as deprecated has the benefit that users won’t see any
>> >> deprecation warnings on the next release. Conversely, deprecating it
>> will
>> >> mean we can choose to remove this, now pointless class, in the future
>> if we
>> >> choose.
>> >>
>> >> That’s my thinking for deprecation, but as I’ve said I’m happy either
>> way.
>> >>
>> >> Andy
>> >>
>> >>> On 18 Jun 2019, at 16:09, Ismael Juma <is...@juma.me.uk> wrote:
>> >>>
>> >>> I agree with Ryanne, I think we should avoid deprecating AdminClient
>> and
>> >>> causing so much churn for users who don't actually care about this
>> niche
>> >>> use case.
>> >>>
>> >>> Ismael
>> >>>
>> >>> On Tue, Jun 18, 2019 at 6:43 AM Andy Coates <an...@confluent.io>
>> wrote:
>> >>>
>> >>>> Hi Ryanne,
>> >>>>
>> >>>> If we don't change the client code, then everywhere will still expect
>> >>>> subclasses of `AdminClient`, so the interface will be of no use,
>> i.e. I
>> >>>> can't write a class that implements the new interface and pass it to
>> the
>> >>>> client code.
>> >>>>
>> >>>> Thanks,
>> >>>>
>> >>>> Andy
>> >>>>
>> >>>> On Mon, 17 Jun 2019 at 19:01, Ryanne Dolan <ry...@gmail.com>
>> >> wrote:
>> >>>>
>> >>>>> Andy, while I agree that the new interface is useful, I'm not
>> convinced
>> >>>>> adding an interface requires deprecating AdminClient and changing so
>> >> much
>> >>>>> client code. Why not just add the Admin interface, have AdminClient
>> >>>>> implement it, and have done?
>> >>>>>
>> >>>>> Ryanne
>> >>>>>
>> >>>>> On Mon, Jun 17, 2019 at 12:09 PM Andy Coates <an...@confluent.io>
>> >> wrote:
>> >>>>>
>> >>>>>> Hi all,
>> >>>>>>
>> >>>>>> I think I've addressed all concerns. Let me know if I've not.  Can
>> I
>> >>>> call
>> >>>>>> another round of votes please?
>> >>>>>>
>> >>>>>> Thanks,
>> >>>>>>
>> >>>>>> Andy
>> >>>>>>
>> >>>>>> On Fri, 14 Jun 2019 at 04:55, Satish Duggana <
>> >> satish.duggana@gmail.com
>> >>>>>
>> >>>>>> wrote:
>> >>>>>>
>> >>>>>>> Hi Andy,
>> >>>>>>> Thanks for the KIP. This is a good change and it gives the user a
>> >>>>> better
>> >>>>>>> handle on Admin client usage. I agree with the proposal except the
>> >>>> new
>> >>>>>>> `Admin` interface having all the methods from `AdminClient`
>> abstract
>> >>>>>> class.
>> >>>>>>> It should be kept clean having only the admin operations as
>> methods
>> >>>>> from
>> >>>>>>> KafkaClient abstract class but not the factory methods as
>> mentioned
>> >>>> in
>> >>>>>> the
>> >>>>>>> earlier mail.
>> >>>>>>>
>> >>>>>>> I know about dynamic proxies(which were widely used in RMI/EJB
>> >>>> world).
>> >>>>> I
>> >>>>>> am
>> >>>>>>> curious about the usecase using dynamic proxies with Admin client
>> >>>>>>> interface. Dynamic proxy can have performance penalty if it is
>> used
>> >>>> in
>> >>>>>>> critical path. Is that the primary motivation for creating the
>> KIP?
>> >>>>>>>
>> >>>>>>> Thanks,
>> >>>>>>> Satish.
>> >>>>>>>
>> >>>>>>> On Wed, Jun 12, 2019 at 8:43 PM Andy Coates <an...@confluent.io>
>> >>>> wrote:
>> >>>>>>>
>> >>>>>>>> I'm not married to that part.  That was only done to keep it more
>> >>>> or
>> >>>>>> less
>> >>>>>>>> inline with what's already there, (an abstract class that has a
>> >>>>> factory
>> >>>>>>>> method that returns a subclass.... sounds like the same
>> >>>> anti-pattern
>> >>>>>> ;))
>> >>>>>>>>
>> >>>>>>>> An alternative would to have an `AdminClients` utility class to
>> >>>>> create
>> >>>>>>> the
>> >>>>>>>> admin client.
>> >>>>>>>>
>> >>>>>>>> On Mon, 10 Jun 2019 at 19:31, Matthias J. Sax <
>> >>>> matthias@confluent.io
>> >>>>>>
>> >>>>>>>> wrote:
>> >>>>>>>>
>> >>>>>>>>> Hmmm...
>> >>>>>>>>>
>> >>>>>>>>> So the new interface, returns an instance of a class that
>> >>>>> implements
>> >>>>>>> the
>> >>>>>>>>> interface. This sounds a little bit like an anti-pattern?
>> >>>> Shouldn't
>> >>>>>>>>> interfaces actually not know anything about classes that
>> >>>> implement
>> >>>>>> the
>> >>>>>>>>> interface?
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>> -Matthias
>> >>>>>>>>>
>> >>>>>>>>> On 6/10/19 11:22 AM, Andy Coates wrote:
>> >>>>>>>>>> `AdminClient` would be deprecated purely because it would no
>> >>>>> longer
>> >>>>>>>> serve
>> >>>>>>>>>> any purpose and would be virtually empty, getting all of its
>> >>>>>>>>> implementation
>> >>>>>>>>>> from the new interfar. It would be nice to remove this from the
>> >>>>> API
>> >>>>>>> at
>> >>>>>>>>> the
>> >>>>>>>>>> next major version bump, hence the need to deprecate.
>> >>>>>>>>>>
>> >>>>>>>>>> `AdminClient.create()` would return what it does today, (so
>> >>>> not a
>> >>>>>>>>> breaking
>> >>>>>>>>>> change).
>> >>>>>>>>>>
>> >>>>>>>>>> On Tue, 4 Jun 2019 at 22:24, Ryanne Dolan <
>> >>>> ryannedolan@gmail.com
>> >>>>>>
>> >>>>>>>> wrote:
>> >>>>>>>>>>
>> >>>>>>>>>>>> The existing `AdminClient` will be marked as deprecated.
>> >>>>>>>>>>>
>> >>>>>>>>>>> What's the reasoning behind this? I'm fine with the other
>> >>>>> changes,
>> >>>>>>> but
>> >>>>>>>>>>> would prefer to keep the existing public API intact if it's
>> >>>> not
>> >>>>>>>> hurting
>> >>>>>>>>>>> anything.
>> >>>>>>>>>>>
>> >>>>>>>>>>> Also, what will AdminClient.create() return? Would it be a
>> >>>>>> breaking
>> >>>>>>>>> change?
>> >>>>>>>>>>>
>> >>>>>>>>>>> Ryanne
>> >>>>>>>>>>>
>> >>>>>>>>>>> On Tue, Jun 4, 2019, 11:17 AM Andy Coates <an...@confluent.io>
>> >>>>>>> wrote:
>> >>>>>>>>>>>
>> >>>>>>>>>>>> Hi folks
>> >>>>>>>>>>>>
>> >>>>>>>>>>>> As there's been no chatter on this KIP I'm assuming it's
>> >>>>>>>>> non-contentious,
>> >>>>>>>>>>>> (or just boring), hence I'd like to call a vote for KIP-476:
>> >>>>>>>>>>>>
>> >>>>>>>>>>>>
>> >>>>>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>
>> >>>>>>>
>> >>>>>>
>> >>>>>
>> >>>>
>> >>
>> https://cwiki.apache.org/confluence/display/KAFKA/KIP-476%3A+Add+Java+AdminClient+Interface
>> >>>>>>>>>>>>
>> >>>>>>>>>>>> Thanks,
>> >>>>>>>>>>>>
>> >>>>>>>>>>>> Andy
>> >>>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>
>> >>>>>>>
>> >>>>>>
>> >>>>>
>> >>>>
>> >>
>> >>
>> >
>>
>>

Re: [VOTE] KIP-476: Add Java AdminClient interface

Posted by Andy Coates <an...@confluent.io>.

Done.

On Thu, 27 Jun 2019 at 23:21, Matthias J. Sax <ma...@confluent.io> wrote:

> @Andy:
>
> What about the factory methods of `AdminClient` class? Should they be
> deprecated?
>
> One nit about the KIP: can you maybe insert "code blocks" to highlight
> the API changes? Code blocks would simplify to read the KIP a lot.
>
>
> -Matthias
>
> On 6/26/19 6:56 AM, Ryanne Dolan wrote:
> > +1 (non-binding)
> >
> > Thanks.
> > Ryanne
> >
> > On Tue, Jun 25, 2019 at 10:21 PM Satish Duggana <
> satish.duggana@gmail.com>
> > wrote:
> >
> >> +1 (non-binding)
> >>
> >> On Wed, Jun 26, 2019 at 8:37 AM Satish Duggana <
> satish.duggana@gmail.com>
> >> wrote:
> >>>
> >>> +1 Matthias/Andy.
> >>> IMHO, interface is about the contract, it should not have/expose any
> >>> implementation. I am fine with either way as it is more of taste or
> >>> preference.
> >>>
> >>> Agree with Ismael/Colin/Ryanne on not deprecating for good reasons.
> >>>
> >>>
> >>> On Mon, Jun 24, 2019 at 8:33 PM Andy Coates <an...@confluent.io> wrote:
> >>>>
> >>>> I agree Matthias.
> >>>>
> >>>> (In Scala, such factory methods are on a companion object. As Java
> >> doesn't
> >>>> have the concept of a companion object, an equivalent would be a
> >> utility
> >>>> class with a similar name...)
> >>>>
> >>>> However, I'll update the KIP to include the factory method on the
> >> interface.
> >>>>
> >>>> On Fri, 21 Jun 2019 at 23:40, Matthias J. Sax <ma...@confluent.io>
> >> wrote:
> >>>>
> >>>>> I still think, that an interface does not need to know anything about
> >>>>> its implementation. But I am also fine if we add a factory method to
> >> the
> >>>>> new interface if that is preferred by most people.
> >>>>>
> >>>>>
> >>>>> -Matthias
> >>>>>
> >>>>> On 6/21/19 7:10 AM, Ismael Juma wrote:
> >>>>>> This is even more reason not to deprecate immediately, there is
> >> very
> >>>>> little
> >>>>>> maintenance cost for us. We should be mindful that many of our
> >> users (eg
> >>>>>> Spark, Flink, etc.) typically allow users to specify the kafka
> >> clients
> >>>>>> version and hence avoid using new classes/interfaces for some
> >> time. They
> >>>>>> would get a bunch of warnings they cannot do anything about apart
> >> from
> >>>>>> suppressing.
> >>>>>>
> >>>>>> Ismael
> >>>>>>
> >>>>>> On Fri, Jun 21, 2019 at 4:00 AM Andy Coates <an...@confluent.io>
> >> wrote:
> >>>>>>
> >>>>>>> Hi Ismael,
> >>>>>>>
> >>>>>>> I’m happy enough to not deprecate the existing `AdminClient`
> >> class as
> >>>>> part
> >>>>>>> of this change.
> >>>>>>>
> >>>>>>> However, note that, the class will likely be empty, i.e. all
> >> methods and
> >>>>>>> implementations will be inherited from the interface:
> >>>>>>>
> >>>>>>> public abstract class AdminClient implements Admin {
> >>>>>>> }
> >>>>>>>
> >>>>>>> Not marking it as deprecated has the benefit that users won’t see
> >> any
> >>>>>>> deprecation warnings on the next release. Conversely, deprecating
> >> it
> >>>>> will
> >>>>>>> mean we can choose to remove this, now pointless class, in the
> >> future
> >>>>> if we
> >>>>>>> choose.
> >>>>>>>
> >>>>>>> That’s my thinking for deprecation, but as I’ve said I’m happy
> >> either
> >>>>> way.
> >>>>>>>
> >>>>>>> Andy
> >>>>>>>
> >>>>>>>> On 18 Jun 2019, at 16:09, Ismael Juma <is...@juma.me.uk> wrote:
> >>>>>>>>
> >>>>>>>> I agree with Ryanne, I think we should avoid deprecating
> >> AdminClient
> >>>>> and
> >>>>>>>> causing so much churn for users who don't actually care about
> >> this
> >>>>> niche
> >>>>>>>> use case.
> >>>>>>>>
> >>>>>>>> Ismael
> >>>>>>>>
> >>>>>>>> On Tue, Jun 18, 2019 at 6:43 AM Andy Coates <an...@confluent.io>
> >> wrote:
> >>>>>>>>
> >>>>>>>>> Hi Ryanne,
> >>>>>>>>>
> >>>>>>>>> If we don't change the client code, then everywhere will still
> >> expect
> >>>>>>>>> subclasses of `AdminClient`, so the interface will be of no
> >> use, i.e.
> >>>>> I
> >>>>>>>>> can't write a class that implements the new interface and pass
> >> it to
> >>>>> the
> >>>>>>>>> client code.
> >>>>>>>>>
> >>>>>>>>> Thanks,
> >>>>>>>>>
> >>>>>>>>> Andy
> >>>>>>>>>
> >>>>>>>>> On Mon, 17 Jun 2019 at 19:01, Ryanne Dolan <
> >> ryannedolan@gmail.com>
> >>>>>>> wrote:
> >>>>>>>>>
> >>>>>>>>>> Andy, while I agree that the new interface is useful, I'm not
> >>>>> convinced
> >>>>>>>>>> adding an interface requires deprecating AdminClient and
> >> changing so
> >>>>>>> much
> >>>>>>>>>> client code. Why not just add the Admin interface, have
> >> AdminClient
> >>>>>>>>>> implement it, and have done?
> >>>>>>>>>>
> >>>>>>>>>> Ryanne
> >>>>>>>>>>
> >>>>>>>>>> On Mon, Jun 17, 2019 at 12:09 PM Andy Coates <
> >> andy@confluent.io>
> >>>>>>> wrote:
> >>>>>>>>>>
> >>>>>>>>>>> Hi all,
> >>>>>>>>>>>
> >>>>>>>>>>> I think I've addressed all concerns. Let me know if I've
> >> not.  Can I
> >>>>>>>>> call
> >>>>>>>>>>> another round of votes please?
> >>>>>>>>>>>
> >>>>>>>>>>> Thanks,
> >>>>>>>>>>>
> >>>>>>>>>>> Andy
> >>>>>>>>>>>
> >>>>>>>>>>> On Fri, 14 Jun 2019 at 04:55, Satish Duggana <
> >>>>>>> satish.duggana@gmail.com
> >>>>>>>>>>
> >>>>>>>>>>> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>>> Hi Andy,
> >>>>>>>>>>>> Thanks for the KIP. This is a good change and it gives the
> >> user a
> >>>>>>>>>> better
> >>>>>>>>>>>> handle on Admin client usage. I agree with the proposal
> >> except the
> >>>>>>>>> new
> >>>>>>>>>>>> `Admin` interface having all the methods from `AdminClient`
> >>>>> abstract
> >>>>>>>>>>> class.
> >>>>>>>>>>>> It should be kept clean having only the admin operations as
> >> methods
> >>>>>>>>>> from
> >>>>>>>>>>>> KafkaClient abstract class but not the factory methods as
> >> mentioned
> >>>>>>>>> in
> >>>>>>>>>>> the
> >>>>>>>>>>>> earlier mail.
> >>>>>>>>>>>>
> >>>>>>>>>>>> I know about dynamic proxies(which were widely used in
> >> RMI/EJB
> >>>>>>>>> world).
> >>>>>>>>>> I
> >>>>>>>>>>> am
> >>>>>>>>>>>> curious about the usecase using dynamic proxies with Admin
> >> client
> >>>>>>>>>>>> interface. Dynamic proxy can have performance penalty if it
> >> is used
> >>>>>>>>> in
> >>>>>>>>>>>> critical path. Is that the primary motivation for creating
> >> the KIP?
> >>>>>>>>>>>>
> >>>>>>>>>>>> Thanks,
> >>>>>>>>>>>> Satish.
> >>>>>>>>>>>>
> >>>>>>>>>>>> On Wed, Jun 12, 2019 at 8:43 PM Andy Coates <
> >> andy@confluent.io>
> >>>>>>>>> wrote:
> >>>>>>>>>>>>
> >>>>>>>>>>>>> I'm not married to that part.  That was only done to keep
> >> it more
> >>>>>>>>> or
> >>>>>>>>>>> less
> >>>>>>>>>>>>> inline with what's already there, (an abstract class that
> >> has a
> >>>>>>>>>> factory
> >>>>>>>>>>>>> method that returns a subclass.... sounds like the same
> >>>>>>>>> anti-pattern
> >>>>>>>>>>> ;))
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> An alternative would to have an `AdminClients` utility
> >> class to
> >>>>>>>>>> create
> >>>>>>>>>>>> the
> >>>>>>>>>>>>> admin client.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> On Mon, 10 Jun 2019 at 19:31, Matthias J. Sax <
> >>>>>>>>> matthias@confluent.io
> >>>>>>>>>>>
> >>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> Hmmm...
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> So the new interface, returns an instance of a class that
> >>>>>>>>>> implements
> >>>>>>>>>>>> the
> >>>>>>>>>>>>>> interface. This sounds a little bit like an anti-pattern?
> >>>>>>>>> Shouldn't
> >>>>>>>>>>>>>> interfaces actually not know anything about classes that
> >>>>>>>>> implement
> >>>>>>>>>>> the
> >>>>>>>>>>>>>> interface?
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> -Matthias
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> On 6/10/19 11:22 AM, Andy Coates wrote:
> >>>>>>>>>>>>>>> `AdminClient` would be deprecated purely because it would
> >> no
> >>>>>>>>>> longer
> >>>>>>>>>>>>> serve
> >>>>>>>>>>>>>>> any purpose and would be virtually empty, getting all of
> >> its
> >>>>>>>>>>>>>> implementation
> >>>>>>>>>>>>>>> from the new interfar. It would be nice to remove this
> >> from the
> >>>>>>>>>> API
> >>>>>>>>>>>> at
> >>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>> next major version bump, hence the need to deprecate.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> `AdminClient.create()` would return what it does today,
> >> (so
> >>>>>>>>> not a
> >>>>>>>>>>>>>> breaking
> >>>>>>>>>>>>>>> change).
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> On Tue, 4 Jun 2019 at 22:24, Ryanne Dolan <
> >>>>>>>>> ryannedolan@gmail.com
> >>>>>>>>>>>
> >>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> The existing `AdminClient` will be marked as deprecated.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> What's the reasoning behind this? I'm fine with the other
> >>>>>>>>>> changes,
> >>>>>>>>>>>> but
> >>>>>>>>>>>>>>>> would prefer to keep the existing public API intact if
> >> it's
> >>>>>>>>> not
> >>>>>>>>>>>>> hurting
> >>>>>>>>>>>>>>>> anything.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Also, what will AdminClient.create() return? Would it be
> >> a
> >>>>>>>>>>> breaking
> >>>>>>>>>>>>>> change?
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Ryanne
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> On Tue, Jun 4, 2019, 11:17 AM Andy Coates <
> >> andy@confluent.io>
> >>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Hi folks
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> As there's been no chatter on this KIP I'm assuming it's
> >>>>>>>>>>>>>> non-contentious,
> >>>>>>>>>>>>>>>>> (or just boring), hence I'd like to call a vote for
> >> KIP-476:
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>
> >>>>>
> >>
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-476%3A+Add+Java+AdminClient+Interface
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Thanks,
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Andy
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>
> >
>
>

Re: [VOTE] KIP-476: Add Java AdminClient interface

Posted by Andy Coates <an...@confluent.io>.

Hi all,

Just a quick note to let you all know that the KIP ran into a slight hiccup
along the way.  The original change saw the return value of
`KafkaClientSupplier.getAdminClient` changed from `AdminClient` to the new
`Admin`, thereby allowing implementers to return a proxy is they so
wanted.  However, changing the return value from the class to the interface
was a binary incompatible change - doh!  Hence the KIP has been updated to
instead leave `getAdminClient`s signature as-is and just deprecate it in
favour of a new `Admin getAdmin(final Map<String, Object> config)` method.

PR here: https://github.com/apache/kafka/pull/7162

Let me know if anyone has any issues / suggestions, etc.

Andy

On Fri, 12 Jul 2019 at 20:35, Andy Coates <an...@confluent.io> wrote:

> Awesome sauce - so I'd like to close the voting. final vote was:
>
> 4 for binding, none against
> 3 non-binding, none against.
>
> I'll update the KIP to reflect the passing of the vote.
>
> Thanks you all for your time & brain power,
>
> Andy
>
> On Thu, 11 Jul 2019 at 14:51, Rajini Sivaram <ra...@gmail.com>
> wrote:
>
>> +1 (binding)
>>
>> Thanks for the KIP, Andy!
>>
>> Regards,
>>
>> Rajini
>>
>>
>> On Thu, Jul 11, 2019 at 1:18 PM Gwen Shapira <gw...@confluent.io> wrote:
>>
>> > +1 (binding)
>> >
>> > Thank you for the improvement.
>> >
>> > On Thu, Jul 11, 2019, 3:53 AM Andy Coates <an...@confluent.io> wrote:
>> >
>> > > Hi All,
>> > >
>> > > So voting currently stands on:
>> > >
>> > > Binding:
>> > > +1 Matthias,
>> > > +1 Colin
>> > >
>> > > Non-binding:
>> > > +1  Thomas Becker
>> > > +1 Satish Guggana
>> > > +1 Ryan Dolan
>> > >
>> > > So we're still 1 binding vote short. :(
>> > >
>> > >
>> > > On Wed, 3 Jul 2019 at 23:08, Matthias J. Sax <ma...@confluent.io>
>> > > wrote:
>> > >
>> > > > Thanks for the details Colin and Andy.
>> > > >
>> > > > My indent was not to block the KIP, but it seems to be a fair
>> question
>> > > > to ask.
>> > > >
>> > > > I talked to Ismael offline about it and understand his reasoning
>> better
>> > > > now. If we don't deprecate `abstract AdminClient` class, it seems
>> > > > reasonable to not deprecate the corresponding factory methods
>> either.
>> > > >
>> > > >
>> > > > +1 (binding) on the current proposal
>> > > >
>> > > >
>> > > >
>> > > > -Matthias
>> > > >
>> > > > On 7/3/19 5:03 AM, Andy Coates wrote:
>> > > > > Matthias,
>> > > > >
>> > > > > I was referring to platforms such as spark or flink that support
>> > > multiple
>> > > > > versions of the Kafka clients. Ismael mentioned this higher up on
>> the
>> > > > > thread.
>> > > > >
>> > > > > I'd prefer this KIP didn't get held up over somewhat unrelated
>> > change,
>> > > > i.e.
>> > > > > should the factory method be on the interface or utility class.
>> > > Surely,
>> > > > > now would be a great time to change this if we wanted, but we can
>> > also
>> > > > > change this later if we need to.  In the interest of moving
>> forward,
>> > > can
>> > > > I
>> > > > > propose we leave the factory methods as they are in the KIP?
>> > > > >
>> > > > > Thanks,
>> > > > >
>> > > > > Andy
>> > > > >
>> > > > > On Tue, 2 Jul 2019 at 17:14, Colin McCabe <cm...@apache.org>
>> > wrote:
>> > > > >
>> > > > >> On Tue, Jul 2, 2019, at 09:14, Colin McCabe wrote:
>> > > > >>> On Mon, Jul 1, 2019, at 23:30, Matthias J. Sax wrote:
>> > > > >>>> Not sure, if I understand the argument?
>> > > > >>>>
>> > > > >>>> Why would anyone need to support multiple client side versions?
>> > > > >>>> Clients/brokers are forward/backward compatible anyway.
>> > > > >>>
>> > > > >>> When you're using many different libraries, it is helpful if
>> they
>> > > don't
>> > > > >>> impose tight constraints on what versions their dependencies
>> are.
>> > > > >>> Otherwise you can easily get in a situation where the
>> constraints
>> > > can't
>> > > > >>> be satisfied.
>> > > > >>>
>> > > > >>>>
>> > > > >>>> Also, if one really supports multiple client side versions,
>> won't
>> > > they
>> > > > >>>> use multiple shaded dependencies for different versions?
>> > > > >>>
>> > > > >>> Shading the Kafka client doesn't really work, because of how we
>> use
>> > > > >> reflection.
>> > > > >>>
>> > > > >>>>
>> > > > >>>> Last, it's possible to suppress warnings (at least in Java).
>> > > > >>>
>> > > > >>> But not in Scala.  So that does not help (for example), Scala
>> > users.
>> > > > >>
>> > > > >> I meant to write "Spark users" here.
>> > > > >>
>> > > > >> C.
>> > > > >>
>> > > > >>>
>> > > > >>> I agree that in general we should be using deprecation when
>> > > > >>> appropriate, regardless of the potential annoyances to users.
>> But
>> > > I'm
>> > > > >>> not sure deprecating this method is really worth it.
>> > > > >>>
>> > > > >>> best,
>> > > > >>> Colin
>> > > > >>>
>> > > > >>>
>> > > > >>>>
>> > > > >>>> Can you elaborate?
>> > > > >>>>
>> > > > >>>> IMHO, just adding a statement to JavaDocs is a little weak,
>> and at
>> > > > some
>> > > > >>>> point, we need to deprecate those methods anyway if we ever
>> want
>> > to
>> > > > >>>> remove them. The earlier we deprecate them, the earlier we can
>> > > remove
>> > > > >> them.
>> > > > >>>>
>> > > > >>>>
>> > > > >>>> -Matthias
>> > > > >>>>
>> > > > >>>> On 7/1/19 4:22 AM, Andy Coates wrote:
>> > > > >>>>> Done. I've not deprecated the factory methods on the
>> AdminClient
>> > > for
>> > > > >> the
>> > > > >>>>> same reason the AdminClient itself is not deprecated, i.e.
>> this
>> > > > >> would cause
>> > > > >>>>> unavoidable warnings for libraries / platforms that support
>> > > multiple
>> > > > >>>>> versions of Kafka. However, I think we add a note to the Java
>> > docs
>> > > of
>> > > > >>>>> `AdminClient` to indicate that its use, going forward, is
>> > > > >> discouraged in
>> > > > >>>>> favour of the new `Admin` interface and explain why its not
>> been
>> > > > >>>>> deprecated, but that it may/will be removed in a future
>> version.
>> > > > >>>>>
>> > > > >>>>> Regarding factory methods on interfaces: there seems to be
>> some
>> > > > >> difference
>> > > > >>>>> of opinion here. I'm not sure of the best approach to revolve
>> > this.
>> > > > >> At the
>> > > > >>>>> moment the KIP has factory methods on the new `Admin`
>> interface,
>> > > > >> rather
>> > > > >>>>> than some utility class. I prefer the utility class, but this
>> > isn't
>> > > > >> inline
>> > > > >>>>> with the patterns in the code base and some of the core team
>> have
>> > > > >> expressed
>> > > > >>>>> they'd prefer to continue to have the factory methods on the
>> > > > >> interface.
>> > > > >>>>> I'm happy with this if others are.
>> > > > >>>>>
>> > > > >>>>> Thanks,
>> > > > >>>>>
>> > > > >>>>> Andy
>> > > > >>>>>
>> > > > >>>>> On Thu, 27 Jun 2019 at 23:21, Matthias J. Sax <
>> > > matthias@confluent.io
>> > > > >
>> > > > >> wrote:
>> > > > >>>>>
>> > > > >>>>>> @Andy:
>> > > > >>>>>>
>> > > > >>>>>> What about the factory methods of `AdminClient` class? Should
>> > they
>> > > > >> be
>> > > > >>>>>> deprecated?
>> > > > >>>>>>
>> > > > >>>>>> One nit about the KIP: can you maybe insert "code blocks" to
>> > > > >> highlight
>> > > > >>>>>> the API changes? Code blocks would simplify to read the KIP a
>> > lot.
>> > > > >>>>>>
>> > > > >>>>>>
>> > > > >>>>>> -Matthias
>> > > > >>>>>>
>> > > > >>>>>> On 6/26/19 6:56 AM, Ryanne Dolan wrote:
>> > > > >>>>>>> +1 (non-binding)
>> > > > >>>>>>>
>> > > > >>>>>>> Thanks.
>> > > > >>>>>>> Ryanne
>> > > > >>>>>>>
>> > > > >>>>>>> On Tue, Jun 25, 2019 at 10:21 PM Satish Duggana <
>> > > > >>>>>> satish.duggana@gmail.com>
>> > > > >>>>>>> wrote:
>> > > > >>>>>>>
>> > > > >>>>>>>> +1 (non-binding)
>> > > > >>>>>>>>
>> > > > >>>>>>>> On Wed, Jun 26, 2019 at 8:37 AM Satish Duggana <
>> > > > >>>>>> satish.duggana@gmail.com>
>> > > > >>>>>>>> wrote:
>> > > > >>>>>>>>>
>> > > > >>>>>>>>> +1 Matthias/Andy.
>> > > > >>>>>>>>> IMHO, interface is about the contract, it should not
>> > > have/expose
>> > > > >> any
>> > > > >>>>>>>>> implementation. I am fine with either way as it is more of
>> > > taste
>> > > > >> or
>> > > > >>>>>>>>> preference.
>> > > > >>>>>>>>>
>> > > > >>>>>>>>> Agree with Ismael/Colin/Ryanne on not deprecating for good
>> > > > >> reasons.
>> > > > >>>>>>>>>
>> > > > >>>>>>>>>
>> > > > >>>>>>>>> On Mon, Jun 24, 2019 at 8:33 PM Andy Coates <
>> > andy@confluent.io
>> > > >
>> > > > >> wrote:
>> > > > >>>>>>>>>>
>> > > > >>>>>>>>>> I agree Matthias.
>> > > > >>>>>>>>>>
>> > > > >>>>>>>>>> (In Scala, such factory methods are on a companion
>> object.
>> > As
>> > > > >> Java
>> > > > >>>>>>>> doesn't
>> > > > >>>>>>>>>> have the concept of a companion object, an equivalent
>> would
>> > > be a
>> > > > >>>>>>>> utility
>> > > > >>>>>>>>>> class with a similar name...)
>> > > > >>>>>>>>>>
>> > > > >>>>>>>>>> However, I'll update the KIP to include the factory
>> method
>> > on
>> > > > >> the
>> > > > >>>>>>>> interface.
>> > > > >>>>>>>>>>
>> > > > >>>>>>>>>> On Fri, 21 Jun 2019 at 23:40, Matthias J. Sax <
>> > > > >> matthias@confluent.io>
>> > > > >>>>>>>> wrote:
>> > > > >>>>>>>>>>
>> > > > >>>>>>>>>>> I still think, that an interface does not need to know
>> > > > >> anything about
>> > > > >>>>>>>>>>> its implementation. But I am also fine if we add a
>> factory
>> > > > >> method to
>> > > > >>>>>>>> the
>> > > > >>>>>>>>>>> new interface if that is preferred by most people.
>> > > > >>>>>>>>>>>
>> > > > >>>>>>>>>>>
>> > > > >>>>>>>>>>> -Matthias
>> > > > >>>>>>>>>>>
>> > > > >>>>>>>>>>> On 6/21/19 7:10 AM, Ismael Juma wrote:
>> > > > >>>>>>>>>>>> This is even more reason not to deprecate immediately,
>> > there
>> > > > >> is
>> > > > >>>>>>>> very
>> > > > >>>>>>>>>>> little
>> > > > >>>>>>>>>>>> maintenance cost for us. We should be mindful that
>> many of
>> > > our
>> > > > >>>>>>>> users (eg
>> > > > >>>>>>>>>>>> Spark, Flink, etc.) typically allow users to specify
>> the
>> > > kafka
>> > > > >>>>>>>> clients
>> > > > >>>>>>>>>>>> version and hence avoid using new classes/interfaces
>> for
>> > > some
>> > > > >>>>>>>> time. They
>> > > > >>>>>>>>>>>> would get a bunch of warnings they cannot do anything
>> > about
>> > > > >> apart
>> > > > >>>>>>>> from
>> > > > >>>>>>>>>>>> suppressing.
>> > > > >>>>>>>>>>>>
>> > > > >>>>>>>>>>>> Ismael
>> > > > >>>>>>>>>>>>
>> > > > >>>>>>>>>>>> On Fri, Jun 21, 2019 at 4:00 AM Andy Coates <
>> > > > >> andy@confluent.io>
>> > > > >>>>>>>> wrote:
>> > > > >>>>>>>>>>>>
>> > > > >>>>>>>>>>>>> Hi Ismael,
>> > > > >>>>>>>>>>>>>
>> > > > >>>>>>>>>>>>> I’m happy enough to not deprecate the existing
>> > > `AdminClient`
>> > > > >>>>>>>> class as
>> > > > >>>>>>>>>>> part
>> > > > >>>>>>>>>>>>> of this change.
>> > > > >>>>>>>>>>>>>
>> > > > >>>>>>>>>>>>> However, note that, the class will likely be empty,
>> i.e.
>> > > all
>> > > > >>>>>>>> methods and
>> > > > >>>>>>>>>>>>> implementations will be inherited from the interface:
>> > > > >>>>>>>>>>>>>
>> > > > >>>>>>>>>>>>> public abstract class AdminClient implements Admin {
>> > > > >>>>>>>>>>>>> }
>> > > > >>>>>>>>>>>>>
>> > > > >>>>>>>>>>>>> Not marking it as deprecated has the benefit that
>> users
>> > > > >> won’t see
>> > > > >>>>>>>> any
>> > > > >>>>>>>>>>>>> deprecation warnings on the next release. Conversely,
>> > > > >> deprecating
>> > > > >>>>>>>> it
>> > > > >>>>>>>>>>> will
>> > > > >>>>>>>>>>>>> mean we can choose to remove this, now pointless
>> class,
>> > in
>> > > > >> the
>> > > > >>>>>>>> future
>> > > > >>>>>>>>>>> if we
>> > > > >>>>>>>>>>>>> choose.
>> > > > >>>>>>>>>>>>>
>> > > > >>>>>>>>>>>>> That’s my thinking for deprecation, but as I’ve said
>> I’m
>> > > > >> happy
>> > > > >>>>>>>> either
>> > > > >>>>>>>>>>> way.
>> > > > >>>>>>>>>>>>>
>> > > > >>>>>>>>>>>>> Andy
>> > > > >>>>>>>>>>>>>
>> > > > >>>>>>>>>>>>>> On 18 Jun 2019, at 16:09, Ismael Juma <
>> > ismael@juma.me.uk>
>> > > > >> wrote:
>> > > > >>>>>>>>>>>>>>
>> > > > >>>>>>>>>>>>>> I agree with Ryanne, I think we should avoid
>> deprecating
>> > > > >>>>>>>> AdminClient
>> > > > >>>>>>>>>>> and
>> > > > >>>>>>>>>>>>>> causing so much churn for users who don't actually
>> care
>> > > > >> about
>> > > > >>>>>>>> this
>> > > > >>>>>>>>>>> niche
>> > > > >>>>>>>>>>>>>> use case.
>> > > > >>>>>>>>>>>>>>
>> > > > >>>>>>>>>>>>>> Ismael
>> > > > >>>>>>>>>>>>>>
>> > > > >>>>>>>>>>>>>> On Tue, Jun 18, 2019 at 6:43 AM Andy Coates <
>> > > > >> andy@confluent.io>
>> > > > >>>>>>>> wrote:
>> > > > >>>>>>>>>>>>>>
>> > > > >>>>>>>>>>>>>>> Hi Ryanne,
>> > > > >>>>>>>>>>>>>>>
>> > > > >>>>>>>>>>>>>>> If we don't change the client code, then everywhere
>> > will
>> > > > >> still
>> > > > >>>>>>>> expect
>> > > > >>>>>>>>>>>>>>> subclasses of `AdminClient`, so the interface will
>> be
>> > of
>> > > no
>> > > > >>>>>>>> use, i.e.
>> > > > >>>>>>>>>>> I
>> > > > >>>>>>>>>>>>>>> can't write a class that implements the new
>> interface
>> > and
>> > > > >> pass
>> > > > >>>>>>>> it to
>> > > > >>>>>>>>>>> the
>> > > > >>>>>>>>>>>>>>> client code.
>> > > > >>>>>>>>>>>>>>>
>> > > > >>>>>>>>>>>>>>> Thanks,
>> > > > >>>>>>>>>>>>>>>
>> > > > >>>>>>>>>>>>>>> Andy
>> > > > >>>>>>>>>>>>>>>
>> > > > >>>>>>>>>>>>>>> On Mon, 17 Jun 2019 at 19:01, Ryanne Dolan <
>> > > > >>>>>>>> ryannedolan@gmail.com>
>> > > > >>>>>>>>>>>>> wrote:
>> > > > >>>>>>>>>>>>>>>
>> > > > >>>>>>>>>>>>>>>> Andy, while I agree that the new interface is
>> useful,
>> > > I'm
>> > > > >> not
>> > > > >>>>>>>>>>> convinced
>> > > > >>>>>>>>>>>>>>>> adding an interface requires deprecating
>> AdminClient
>> > and
>> > > > >>>>>>>> changing so
>> > > > >>>>>>>>>>>>> much
>> > > > >>>>>>>>>>>>>>>> client code. Why not just add the Admin interface,
>> > have
>> > > > >>>>>>>> AdminClient
>> > > > >>>>>>>>>>>>>>>> implement it, and have done?
>> > > > >>>>>>>>>>>>>>>>
>> > > > >>>>>>>>>>>>>>>> Ryanne
>> > > > >>>>>>>>>>>>>>>>
>> > > > >>>>>>>>>>>>>>>> On Mon, Jun 17, 2019 at 12:09 PM Andy Coates <
>> > > > >>>>>>>> andy@confluent.io>
>> > > > >>>>>>>>>>>>> wrote:
>> > > > >>>>>>>>>>>>>>>>
>> > > > >>>>>>>>>>>>>>>>> Hi all,
>> > > > >>>>>>>>>>>>>>>>>
>> > > > >>>>>>>>>>>>>>>>> I think I've addressed all concerns. Let me know
>> if
>> > > I've
>> > > > >>>>>>>> not.  Can I
>> > > > >>>>>>>>>>>>>>> call
>> > > > >>>>>>>>>>>>>>>>> another round of votes please?
>> > > > >>>>>>>>>>>>>>>>>
>> > > > >>>>>>>>>>>>>>>>> Thanks,
>> > > > >>>>>>>>>>>>>>>>>
>> > > > >>>>>>>>>>>>>>>>> Andy
>> > > > >>>>>>>>>>>>>>>>>
>> > > > >>>>>>>>>>>>>>>>> On Fri, 14 Jun 2019 at 04:55, Satish Duggana <
>> > > > >>>>>>>>>>>>> satish.duggana@gmail.com
>> > > > >>>>>>>>>>>>>>>>
>> > > > >>>>>>>>>>>>>>>>> wrote:
>> > > > >>>>>>>>>>>>>>>>>
>> > > > >>>>>>>>>>>>>>>>>> Hi Andy,
>> > > > >>>>>>>>>>>>>>>>>> Thanks for the KIP. This is a good change and it
>> > gives
>> > > > >> the
>> > > > >>>>>>>> user a
>> > > > >>>>>>>>>>>>>>>> better
>> > > > >>>>>>>>>>>>>>>>>> handle on Admin client usage. I agree with the
>> > > proposal
>> > > > >>>>>>>> except the
>> > > > >>>>>>>>>>>>>>> new
>> > > > >>>>>>>>>>>>>>>>>> `Admin` interface having all the methods from
>> > > > >> `AdminClient`
>> > > > >>>>>>>>>>> abstract
>> > > > >>>>>>>>>>>>>>>>> class.
>> > > > >>>>>>>>>>>>>>>>>> It should be kept clean having only the admin
>> > > > >> operations as
>> > > > >>>>>>>> methods
>> > > > >>>>>>>>>>>>>>>> from
>> > > > >>>>>>>>>>>>>>>>>> KafkaClient abstract class but not the factory
>> > methods
>> > > > >> as
>> > > > >>>>>>>> mentioned
>> > > > >>>>>>>>>>>>>>> in
>> > > > >>>>>>>>>>>>>>>>> the
>> > > > >>>>>>>>>>>>>>>>>> earlier mail.
>> > > > >>>>>>>>>>>>>>>>>>
>> > > > >>>>>>>>>>>>>>>>>> I know about dynamic proxies(which were widely
>> used
>> > in
>> > > > >>>>>>>> RMI/EJB
>> > > > >>>>>>>>>>>>>>> world).
>> > > > >>>>>>>>>>>>>>>> I
>> > > > >>>>>>>>>>>>>>>>> am
>> > > > >>>>>>>>>>>>>>>>>> curious about the usecase using dynamic proxies
>> with
>> > > > >> Admin
>> > > > >>>>>>>> client
>> > > > >>>>>>>>>>>>>>>>>> interface. Dynamic proxy can have performance
>> > penalty
>> > > > >> if it
>> > > > >>>>>>>> is used
>> > > > >>>>>>>>>>>>>>> in
>> > > > >>>>>>>>>>>>>>>>>> critical path. Is that the primary motivation for
>> > > > >> creating
>> > > > >>>>>>>> the KIP?
>> > > > >>>>>>>>>>>>>>>>>>
>> > > > >>>>>>>>>>>>>>>>>> Thanks,
>> > > > >>>>>>>>>>>>>>>>>> Satish.
>> > > > >>>>>>>>>>>>>>>>>>
>> > > > >>>>>>>>>>>>>>>>>> On Wed, Jun 12, 2019 at 8:43 PM Andy Coates <
>> > > > >>>>>>>> andy@confluent.io>
>> > > > >>>>>>>>>>>>>>> wrote:
>> > > > >>>>>>>>>>>>>>>>>>
>> > > > >>>>>>>>>>>>>>>>>>> I'm not married to that part.  That was only
>> done
>> > to
>> > > > >> keep
>> > > > >>>>>>>> it more
>> > > > >>>>>>>>>>>>>>> or
>> > > > >>>>>>>>>>>>>>>>> less
>> > > > >>>>>>>>>>>>>>>>>>> inline with what's already there, (an abstract
>> > class
>> > > > >> that
>> > > > >>>>>>>> has a
>> > > > >>>>>>>>>>>>>>>> factory
>> > > > >>>>>>>>>>>>>>>>>>> method that returns a subclass.... sounds like
>> the
>> > > same
>> > > > >>>>>>>>>>>>>>> anti-pattern
>> > > > >>>>>>>>>>>>>>>>> ;))
>> > > > >>>>>>>>>>>>>>>>>>>
>> > > > >>>>>>>>>>>>>>>>>>> An alternative would to have an `AdminClients`
>> > > utility
>> > > > >>>>>>>> class to
>> > > > >>>>>>>>>>>>>>>> create
>> > > > >>>>>>>>>>>>>>>>>> the
>> > > > >>>>>>>>>>>>>>>>>>> admin client.
>> > > > >>>>>>>>>>>>>>>>>>>
>> > > > >>>>>>>>>>>>>>>>>>> On Mon, 10 Jun 2019 at 19:31, Matthias J. Sax <
>> > > > >>>>>>>>>>>>>>> matthias@confluent.io
>> > > > >>>>>>>>>>>>>>>>>
>> > > > >>>>>>>>>>>>>>>>>>> wrote:
>> > > > >>>>>>>>>>>>>>>>>>>
>> > > > >>>>>>>>>>>>>>>>>>>> Hmmm...
>> > > > >>>>>>>>>>>>>>>>>>>>
>> > > > >>>>>>>>>>>>>>>>>>>> So the new interface, returns an instance of a
>> > class
>> > > > >> that
>> > > > >>>>>>>>>>>>>>>> implements
>> > > > >>>>>>>>>>>>>>>>>> the
>> > > > >>>>>>>>>>>>>>>>>>>> interface. This sounds a little bit like an
>> > > > >> anti-pattern?
>> > > > >>>>>>>>>>>>>>> Shouldn't
>> > > > >>>>>>>>>>>>>>>>>>>> interfaces actually not know anything about
>> > classes
>> > > > >> that
>> > > > >>>>>>>>>>>>>>> implement
>> > > > >>>>>>>>>>>>>>>>> the
>> > > > >>>>>>>>>>>>>>>>>>>> interface?
>> > > > >>>>>>>>>>>>>>>>>>>>
>> > > > >>>>>>>>>>>>>>>>>>>>
>> > > > >>>>>>>>>>>>>>>>>>>> -Matthias
>> > > > >>>>>>>>>>>>>>>>>>>>
>> > > > >>>>>>>>>>>>>>>>>>>> On 6/10/19 11:22 AM, Andy Coates wrote:
>> > > > >>>>>>>>>>>>>>>>>>>>> `AdminClient` would be deprecated purely
>> because
>> > it
>> > > > >> would
>> > > > >>>>>>>> no
>> > > > >>>>>>>>>>>>>>>> longer
>> > > > >>>>>>>>>>>>>>>>>>> serve
>> > > > >>>>>>>>>>>>>>>>>>>>> any purpose and would be virtually empty,
>> getting
>> > > > >> all of
>> > > > >>>>>>>> its
>> > > > >>>>>>>>>>>>>>>>>>>> implementation
>> > > > >>>>>>>>>>>>>>>>>>>>> from the new interfar. It would be nice to
>> remove
>> > > > >> this
>> > > > >>>>>>>> from the
>> > > > >>>>>>>>>>>>>>>> API
>> > > > >>>>>>>>>>>>>>>>>> at
>> > > > >>>>>>>>>>>>>>>>>>>> the
>> > > > >>>>>>>>>>>>>>>>>>>>> next major version bump, hence the need to
>> > > deprecate.
>> > > > >>>>>>>>>>>>>>>>>>>>>
>> > > > >>>>>>>>>>>>>>>>>>>>> `AdminClient.create()` would return what it
>> does
>> > > > >> today,
>> > > > >>>>>>>> (so
>> > > > >>>>>>>>>>>>>>> not a
>> > > > >>>>>>>>>>>>>>>>>>>> breaking
>> > > > >>>>>>>>>>>>>>>>>>>>> change).
>> > > > >>>>>>>>>>>>>>>>>>>>>
>> > > > >>>>>>>>>>>>>>>>>>>>> On Tue, 4 Jun 2019 at 22:24, Ryanne Dolan <
>> > > > >>>>>>>>>>>>>>> ryannedolan@gmail.com
>> > > > >>>>>>>>>>>>>>>>>
>> > > > >>>>>>>>>>>>>>>>>>> wrote:
>> > > > >>>>>>>>>>>>>>>>>>>>>
>> > > > >>>>>>>>>>>>>>>>>>>>>>> The existing `AdminClient` will be marked as
>> > > > >> deprecated.
>> > > > >>>>>>>>>>>>>>>>>>>>>>
>> > > > >>>>>>>>>>>>>>>>>>>>>> What's the reasoning behind this? I'm fine
>> with
>> > > the
>> > > > >> other
>> > > > >>>>>>>>>>>>>>>> changes,
>> > > > >>>>>>>>>>>>>>>>>> but
>> > > > >>>>>>>>>>>>>>>>>>>>>> would prefer to keep the existing public API
>> > > intact
>> > > > >> if
>> > > > >>>>>>>> it's
>> > > > >>>>>>>>>>>>>>> not
>> > > > >>>>>>>>>>>>>>>>>>> hurting
>> > > > >>>>>>>>>>>>>>>>>>>>>> anything.
>> > > > >>>>>>>>>>>>>>>>>>>>>>
>> > > > >>>>>>>>>>>>>>>>>>>>>> Also, what will AdminClient.create() return?
>> > Would
>> > > > >> it be
>> > > > >>>>>>>> a
>> > > > >>>>>>>>>>>>>>>>> breaking
>> > > > >>>>>>>>>>>>>>>>>>>> change?
>> > > > >>>>>>>>>>>>>>>>>>>>>>
>> > > > >>>>>>>>>>>>>>>>>>>>>> Ryanne
>> > > > >>>>>>>>>>>>>>>>>>>>>>
>> > > > >>>>>>>>>>>>>>>>>>>>>> On Tue, Jun 4, 2019, 11:17 AM Andy Coates <
>> > > > >>>>>>>> andy@confluent.io>
>> > > > >>>>>>>>>>>>>>>>>> wrote:
>> > > > >>>>>>>>>>>>>>>>>>>>>>
>> > > > >>>>>>>>>>>>>>>>>>>>>>> Hi folks
>> > > > >>>>>>>>>>>>>>>>>>>>>>>
>> > > > >>>>>>>>>>>>>>>>>>>>>>> As there's been no chatter on this KIP I'm
>> > > > >> assuming it's
>> > > > >>>>>>>>>>>>>>>>>>>> non-contentious,
>> > > > >>>>>>>>>>>>>>>>>>>>>>> (or just boring), hence I'd like to call a
>> vote
>> > > for
>> > > > >>>>>>>> KIP-476:
>> > > > >>>>>>>>>>>>>>>>>>>>>>>
>> > > > >>>>>>>>>>>>>>>>>>>>>>>
>> > > > >>>>>>>>>>>>>>>>>>>>>>>
>> > > > >>>>>>>>>>>>>>>>>>>>
>> > > > >>>>>>>>>>>>>>>>>>>
>> > > > >>>>>>>>>>>>>>>>>>
>> > > > >>>>>>>>>>>>>>>>>
>> > > > >>>>>>>>>>>>>>>>
>> > > > >>>>>>>>>>>>>>>
>> > > > >>>>>>>>>>>>>
>> > > > >>>>>>>>>>>
>> > > > >>>>>>>>
>> > > > >>>>>>
>> > > > >>
>> > > >
>> > >
>> >
>> https://cwiki.apache.org/confluence/display/KAFKA/KIP-476%3A+Add+Java+AdminClient+Interface
>> > > > >>>>>>>>>>>>>>>>>>>>>>>
>> > > > >>>>>>>>>>>>>>>>>>>>>>> Thanks,
>> > > > >>>>>>>>>>>>>>>>>>>>>>>
>> > > > >>>>>>>>>>>>>>>>>>>>>>> Andy
>> > > > >>>>>>>>>>>>>>>>>>>>>>>
>> > > > >>>>>>>>>>>>>>>>>>>>>>
>> > > > >>>>>>>>>>>>>>>>>>>>>
>> > > > >>>>>>>>>>>>>>>>>>>>
>> > > > >>>>>>>>>>>>>>>>>>>>
>> > > > >>>>>>>>>>>>>>>>>>>
>> > > > >>>>>>>>>>>>>>>>>>
>> > > > >>>>>>>>>>>>>>>>>
>> > > > >>>>>>>>>>>>>>>>
>> > > > >>>>>>>>>>>>>>>
>> > > > >>>>>>>>>>>>>
>> > > > >>>>>>>>>>>>>
>> > > > >>>>>>>>>>>>
>> > > > >>>>>>>>>>>
>> > > > >>>>>>>>>>>
>> > > > >>>>>>>>
>> > > > >>>>>>>
>> > > > >>>>>>
>> > > > >>>>>>
>> > > > >>>>>
>> > > > >>>>
>> > > > >>>>
>> > > > >>>> Attachments:
>> > > > >>>> * signature.asc
>> > > > >>>
>> > > > >>
>> > > > >
>> > > >
>> > > >
>> > >
>> >
>>
>

Re: [VOTE] KIP-476: Add Java AdminClient interface

Posted by Andy Coates <an...@confluent.io>.

Awesome sauce - so I'd like to close the voting. final vote was:

4 for binding, none against
3 non-binding, none against.

I'll update the KIP to reflect the passing of the vote.

Thanks you all for your time & brain power,

Andy

On Thu, 11 Jul 2019 at 14:51, Rajini Sivaram <ra...@gmail.com>
wrote:

> +1 (binding)
>
> Thanks for the KIP, Andy!
>
> Regards,
>
> Rajini
>
>
> On Thu, Jul 11, 2019 at 1:18 PM Gwen Shapira <gw...@confluent.io> wrote:
>
> > +1 (binding)
> >
> > Thank you for the improvement.
> >
> > On Thu, Jul 11, 2019, 3:53 AM Andy Coates <an...@confluent.io> wrote:
> >
> > > Hi All,
> > >
> > > So voting currently stands on:
> > >
> > > Binding:
> > > +1 Matthias,
> > > +1 Colin
> > >
> > > Non-binding:
> > > +1  Thomas Becker
> > > +1 Satish Guggana
> > > +1 Ryan Dolan
> > >
> > > So we're still 1 binding vote short. :(
> > >
> > >
> > > On Wed, 3 Jul 2019 at 23:08, Matthias J. Sax <ma...@confluent.io>
> > > wrote:
> > >
> > > > Thanks for the details Colin and Andy.
> > > >
> > > > My indent was not to block the KIP, but it seems to be a fair
> question
> > > > to ask.
> > > >
> > > > I talked to Ismael offline about it and understand his reasoning
> better
> > > > now. If we don't deprecate `abstract AdminClient` class, it seems
> > > > reasonable to not deprecate the corresponding factory methods either.
> > > >
> > > >
> > > > +1 (binding) on the current proposal
> > > >
> > > >
> > > >
> > > > -Matthias
> > > >
> > > > On 7/3/19 5:03 AM, Andy Coates wrote:
> > > > > Matthias,
> > > > >
> > > > > I was referring to platforms such as spark or flink that support
> > > multiple
> > > > > versions of the Kafka clients. Ismael mentioned this higher up on
> the
> > > > > thread.
> > > > >
> > > > > I'd prefer this KIP didn't get held up over somewhat unrelated
> > change,
> > > > i.e.
> > > > > should the factory method be on the interface or utility class.
> > > Surely,
> > > > > now would be a great time to change this if we wanted, but we can
> > also
> > > > > change this later if we need to.  In the interest of moving
> forward,
> > > can
> > > > I
> > > > > propose we leave the factory methods as they are in the KIP?
> > > > >
> > > > > Thanks,
> > > > >
> > > > > Andy
> > > > >
> > > > > On Tue, 2 Jul 2019 at 17:14, Colin McCabe <cm...@apache.org>
> > wrote:
> > > > >
> > > > >> On Tue, Jul 2, 2019, at 09:14, Colin McCabe wrote:
> > > > >>> On Mon, Jul 1, 2019, at 23:30, Matthias J. Sax wrote:
> > > > >>>> Not sure, if I understand the argument?
> > > > >>>>
> > > > >>>> Why would anyone need to support multiple client side versions?
> > > > >>>> Clients/brokers are forward/backward compatible anyway.
> > > > >>>
> > > > >>> When you're using many different libraries, it is helpful if they
> > > don't
> > > > >>> impose tight constraints on what versions their dependencies are.
> > > > >>> Otherwise you can easily get in a situation where the constraints
> > > can't
> > > > >>> be satisfied.
> > > > >>>
> > > > >>>>
> > > > >>>> Also, if one really supports multiple client side versions,
> won't
> > > they
> > > > >>>> use multiple shaded dependencies for different versions?
> > > > >>>
> > > > >>> Shading the Kafka client doesn't really work, because of how we
> use
> > > > >> reflection.
> > > > >>>
> > > > >>>>
> > > > >>>> Last, it's possible to suppress warnings (at least in Java).
> > > > >>>
> > > > >>> But not in Scala.  So that does not help (for example), Scala
> > users.
> > > > >>
> > > > >> I meant to write "Spark users" here.
> > > > >>
> > > > >> C.
> > > > >>
> > > > >>>
> > > > >>> I agree that in general we should be using deprecation when
> > > > >>> appropriate, regardless of the potential annoyances to users.
> But
> > > I'm
> > > > >>> not sure deprecating this method is really worth it.
> > > > >>>
> > > > >>> best,
> > > > >>> Colin
> > > > >>>
> > > > >>>
> > > > >>>>
> > > > >>>> Can you elaborate?
> > > > >>>>
> > > > >>>> IMHO, just adding a statement to JavaDocs is a little weak, and
> at
> > > > some
> > > > >>>> point, we need to deprecate those methods anyway if we ever want
> > to
> > > > >>>> remove them. The earlier we deprecate them, the earlier we can
> > > remove
> > > > >> them.
> > > > >>>>
> > > > >>>>
> > > > >>>> -Matthias
> > > > >>>>
> > > > >>>> On 7/1/19 4:22 AM, Andy Coates wrote:
> > > > >>>>> Done. I've not deprecated the factory methods on the
> AdminClient
> > > for
> > > > >> the
> > > > >>>>> same reason the AdminClient itself is not deprecated, i.e. this
> > > > >> would cause
> > > > >>>>> unavoidable warnings for libraries / platforms that support
> > > multiple
> > > > >>>>> versions of Kafka. However, I think we add a note to the Java
> > docs
> > > of
> > > > >>>>> `AdminClient` to indicate that its use, going forward, is
> > > > >> discouraged in
> > > > >>>>> favour of the new `Admin` interface and explain why its not
> been
> > > > >>>>> deprecated, but that it may/will be removed in a future
> version.
> > > > >>>>>
> > > > >>>>> Regarding factory methods on interfaces: there seems to be some
> > > > >> difference
> > > > >>>>> of opinion here. I'm not sure of the best approach to revolve
> > this.
> > > > >> At the
> > > > >>>>> moment the KIP has factory methods on the new `Admin`
> interface,
> > > > >> rather
> > > > >>>>> than some utility class. I prefer the utility class, but this
> > isn't
> > > > >> inline
> > > > >>>>> with the patterns in the code base and some of the core team
> have
> > > > >> expressed
> > > > >>>>> they'd prefer to continue to have the factory methods on the
> > > > >> interface.
> > > > >>>>> I'm happy with this if others are.
> > > > >>>>>
> > > > >>>>> Thanks,
> > > > >>>>>
> > > > >>>>> Andy
> > > > >>>>>
> > > > >>>>> On Thu, 27 Jun 2019 at 23:21, Matthias J. Sax <
> > > matthias@confluent.io
> > > > >
> > > > >> wrote:
> > > > >>>>>
> > > > >>>>>> @Andy:
> > > > >>>>>>
> > > > >>>>>> What about the factory methods of `AdminClient` class? Should
> > they
> > > > >> be
> > > > >>>>>> deprecated?
> > > > >>>>>>
> > > > >>>>>> One nit about the KIP: can you maybe insert "code blocks" to
> > > > >> highlight
> > > > >>>>>> the API changes? Code blocks would simplify to read the KIP a
> > lot.
> > > > >>>>>>
> > > > >>>>>>
> > > > >>>>>> -Matthias
> > > > >>>>>>
> > > > >>>>>> On 6/26/19 6:56 AM, Ryanne Dolan wrote:
> > > > >>>>>>> +1 (non-binding)
> > > > >>>>>>>
> > > > >>>>>>> Thanks.
> > > > >>>>>>> Ryanne
> > > > >>>>>>>
> > > > >>>>>>> On Tue, Jun 25, 2019 at 10:21 PM Satish Duggana <
> > > > >>>>>> satish.duggana@gmail.com>
> > > > >>>>>>> wrote:
> > > > >>>>>>>
> > > > >>>>>>>> +1 (non-binding)
> > > > >>>>>>>>
> > > > >>>>>>>> On Wed, Jun 26, 2019 at 8:37 AM Satish Duggana <
> > > > >>>>>> satish.duggana@gmail.com>
> > > > >>>>>>>> wrote:
> > > > >>>>>>>>>
> > > > >>>>>>>>> +1 Matthias/Andy.
> > > > >>>>>>>>> IMHO, interface is about the contract, it should not
> > > have/expose
> > > > >> any
> > > > >>>>>>>>> implementation. I am fine with either way as it is more of
> > > taste
> > > > >> or
> > > > >>>>>>>>> preference.
> > > > >>>>>>>>>
> > > > >>>>>>>>> Agree with Ismael/Colin/Ryanne on not deprecating for good
> > > > >> reasons.
> > > > >>>>>>>>>
> > > > >>>>>>>>>
> > > > >>>>>>>>> On Mon, Jun 24, 2019 at 8:33 PM Andy Coates <
> > andy@confluent.io
> > > >
> > > > >> wrote:
> > > > >>>>>>>>>>
> > > > >>>>>>>>>> I agree Matthias.
> > > > >>>>>>>>>>
> > > > >>>>>>>>>> (In Scala, such factory methods are on a companion object.
> > As
> > > > >> Java
> > > > >>>>>>>> doesn't
> > > > >>>>>>>>>> have the concept of a companion object, an equivalent
> would
> > > be a
> > > > >>>>>>>> utility
> > > > >>>>>>>>>> class with a similar name...)
> > > > >>>>>>>>>>
> > > > >>>>>>>>>> However, I'll update the KIP to include the factory method
> > on
> > > > >> the
> > > > >>>>>>>> interface.
> > > > >>>>>>>>>>
> > > > >>>>>>>>>> On Fri, 21 Jun 2019 at 23:40, Matthias J. Sax <
> > > > >> matthias@confluent.io>
> > > > >>>>>>>> wrote:
> > > > >>>>>>>>>>
> > > > >>>>>>>>>>> I still think, that an interface does not need to know
> > > > >> anything about
> > > > >>>>>>>>>>> its implementation. But I am also fine if we add a
> factory
> > > > >> method to
> > > > >>>>>>>> the
> > > > >>>>>>>>>>> new interface if that is preferred by most people.
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>>> -Matthias
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>>> On 6/21/19 7:10 AM, Ismael Juma wrote:
> > > > >>>>>>>>>>>> This is even more reason not to deprecate immediately,
> > there
> > > > >> is
> > > > >>>>>>>> very
> > > > >>>>>>>>>>> little
> > > > >>>>>>>>>>>> maintenance cost for us. We should be mindful that many
> of
> > > our
> > > > >>>>>>>> users (eg
> > > > >>>>>>>>>>>> Spark, Flink, etc.) typically allow users to specify the
> > > kafka
> > > > >>>>>>>> clients
> > > > >>>>>>>>>>>> version and hence avoid using new classes/interfaces for
> > > some
> > > > >>>>>>>> time. They
> > > > >>>>>>>>>>>> would get a bunch of warnings they cannot do anything
> > about
> > > > >> apart
> > > > >>>>>>>> from
> > > > >>>>>>>>>>>> suppressing.
> > > > >>>>>>>>>>>>
> > > > >>>>>>>>>>>> Ismael
> > > > >>>>>>>>>>>>
> > > > >>>>>>>>>>>> On Fri, Jun 21, 2019 at 4:00 AM Andy Coates <
> > > > >> andy@confluent.io>
> > > > >>>>>>>> wrote:
> > > > >>>>>>>>>>>>
> > > > >>>>>>>>>>>>> Hi Ismael,
> > > > >>>>>>>>>>>>>
> > > > >>>>>>>>>>>>> I’m happy enough to not deprecate the existing
> > > `AdminClient`
> > > > >>>>>>>> class as
> > > > >>>>>>>>>>> part
> > > > >>>>>>>>>>>>> of this change.
> > > > >>>>>>>>>>>>>
> > > > >>>>>>>>>>>>> However, note that, the class will likely be empty,
> i.e.
> > > all
> > > > >>>>>>>> methods and
> > > > >>>>>>>>>>>>> implementations will be inherited from the interface:
> > > > >>>>>>>>>>>>>
> > > > >>>>>>>>>>>>> public abstract class AdminClient implements Admin {
> > > > >>>>>>>>>>>>> }
> > > > >>>>>>>>>>>>>
> > > > >>>>>>>>>>>>> Not marking it as deprecated has the benefit that users
> > > > >> won’t see
> > > > >>>>>>>> any
> > > > >>>>>>>>>>>>> deprecation warnings on the next release. Conversely,
> > > > >> deprecating
> > > > >>>>>>>> it
> > > > >>>>>>>>>>> will
> > > > >>>>>>>>>>>>> mean we can choose to remove this, now pointless class,
> > in
> > > > >> the
> > > > >>>>>>>> future
> > > > >>>>>>>>>>> if we
> > > > >>>>>>>>>>>>> choose.
> > > > >>>>>>>>>>>>>
> > > > >>>>>>>>>>>>> That’s my thinking for deprecation, but as I’ve said
> I’m
> > > > >> happy
> > > > >>>>>>>> either
> > > > >>>>>>>>>>> way.
> > > > >>>>>>>>>>>>>
> > > > >>>>>>>>>>>>> Andy
> > > > >>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>> On 18 Jun 2019, at 16:09, Ismael Juma <
> > ismael@juma.me.uk>
> > > > >> wrote:
> > > > >>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>> I agree with Ryanne, I think we should avoid
> deprecating
> > > > >>>>>>>> AdminClient
> > > > >>>>>>>>>>> and
> > > > >>>>>>>>>>>>>> causing so much churn for users who don't actually
> care
> > > > >> about
> > > > >>>>>>>> this
> > > > >>>>>>>>>>> niche
> > > > >>>>>>>>>>>>>> use case.
> > > > >>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>> Ismael
> > > > >>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>> On Tue, Jun 18, 2019 at 6:43 AM Andy Coates <
> > > > >> andy@confluent.io>
> > > > >>>>>>>> wrote:
> > > > >>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>> Hi Ryanne,
> > > > >>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>> If we don't change the client code, then everywhere
> > will
> > > > >> still
> > > > >>>>>>>> expect
> > > > >>>>>>>>>>>>>>> subclasses of `AdminClient`, so the interface will be
> > of
> > > no
> > > > >>>>>>>> use, i.e.
> > > > >>>>>>>>>>> I
> > > > >>>>>>>>>>>>>>> can't write a class that implements the new interface
> > and
> > > > >> pass
> > > > >>>>>>>> it to
> > > > >>>>>>>>>>> the
> > > > >>>>>>>>>>>>>>> client code.
> > > > >>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>> Thanks,
> > > > >>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>> Andy
> > > > >>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>> On Mon, 17 Jun 2019 at 19:01, Ryanne Dolan <
> > > > >>>>>>>> ryannedolan@gmail.com>
> > > > >>>>>>>>>>>>> wrote:
> > > > >>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>> Andy, while I agree that the new interface is
> useful,
> > > I'm
> > > > >> not
> > > > >>>>>>>>>>> convinced
> > > > >>>>>>>>>>>>>>>> adding an interface requires deprecating AdminClient
> > and
> > > > >>>>>>>> changing so
> > > > >>>>>>>>>>>>> much
> > > > >>>>>>>>>>>>>>>> client code. Why not just add the Admin interface,
> > have
> > > > >>>>>>>> AdminClient
> > > > >>>>>>>>>>>>>>>> implement it, and have done?
> > > > >>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>> Ryanne
> > > > >>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>> On Mon, Jun 17, 2019 at 12:09 PM Andy Coates <
> > > > >>>>>>>> andy@confluent.io>
> > > > >>>>>>>>>>>>> wrote:
> > > > >>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>> Hi all,
> > > > >>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>> I think I've addressed all concerns. Let me know if
> > > I've
> > > > >>>>>>>> not.  Can I
> > > > >>>>>>>>>>>>>>> call
> > > > >>>>>>>>>>>>>>>>> another round of votes please?
> > > > >>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>> Thanks,
> > > > >>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>> Andy
> > > > >>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>> On Fri, 14 Jun 2019 at 04:55, Satish Duggana <
> > > > >>>>>>>>>>>>> satish.duggana@gmail.com
> > > > >>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>> wrote:
> > > > >>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>> Hi Andy,
> > > > >>>>>>>>>>>>>>>>>> Thanks for the KIP. This is a good change and it
> > gives
> > > > >> the
> > > > >>>>>>>> user a
> > > > >>>>>>>>>>>>>>>> better
> > > > >>>>>>>>>>>>>>>>>> handle on Admin client usage. I agree with the
> > > proposal
> > > > >>>>>>>> except the
> > > > >>>>>>>>>>>>>>> new
> > > > >>>>>>>>>>>>>>>>>> `Admin` interface having all the methods from
> > > > >> `AdminClient`
> > > > >>>>>>>>>>> abstract
> > > > >>>>>>>>>>>>>>>>> class.
> > > > >>>>>>>>>>>>>>>>>> It should be kept clean having only the admin
> > > > >> operations as
> > > > >>>>>>>> methods
> > > > >>>>>>>>>>>>>>>> from
> > > > >>>>>>>>>>>>>>>>>> KafkaClient abstract class but not the factory
> > methods
> > > > >> as
> > > > >>>>>>>> mentioned
> > > > >>>>>>>>>>>>>>> in
> > > > >>>>>>>>>>>>>>>>> the
> > > > >>>>>>>>>>>>>>>>>> earlier mail.
> > > > >>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>> I know about dynamic proxies(which were widely
> used
> > in
> > > > >>>>>>>> RMI/EJB
> > > > >>>>>>>>>>>>>>> world).
> > > > >>>>>>>>>>>>>>>> I
> > > > >>>>>>>>>>>>>>>>> am
> > > > >>>>>>>>>>>>>>>>>> curious about the usecase using dynamic proxies
> with
> > > > >> Admin
> > > > >>>>>>>> client
> > > > >>>>>>>>>>>>>>>>>> interface. Dynamic proxy can have performance
> > penalty
> > > > >> if it
> > > > >>>>>>>> is used
> > > > >>>>>>>>>>>>>>> in
> > > > >>>>>>>>>>>>>>>>>> critical path. Is that the primary motivation for
> > > > >> creating
> > > > >>>>>>>> the KIP?
> > > > >>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>> Thanks,
> > > > >>>>>>>>>>>>>>>>>> Satish.
> > > > >>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>> On Wed, Jun 12, 2019 at 8:43 PM Andy Coates <
> > > > >>>>>>>> andy@confluent.io>
> > > > >>>>>>>>>>>>>>> wrote:
> > > > >>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>> I'm not married to that part.  That was only done
> > to
> > > > >> keep
> > > > >>>>>>>> it more
> > > > >>>>>>>>>>>>>>> or
> > > > >>>>>>>>>>>>>>>>> less
> > > > >>>>>>>>>>>>>>>>>>> inline with what's already there, (an abstract
> > class
> > > > >> that
> > > > >>>>>>>> has a
> > > > >>>>>>>>>>>>>>>> factory
> > > > >>>>>>>>>>>>>>>>>>> method that returns a subclass.... sounds like
> the
> > > same
> > > > >>>>>>>>>>>>>>> anti-pattern
> > > > >>>>>>>>>>>>>>>>> ;))
> > > > >>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>> An alternative would to have an `AdminClients`
> > > utility
> > > > >>>>>>>> class to
> > > > >>>>>>>>>>>>>>>> create
> > > > >>>>>>>>>>>>>>>>>> the
> > > > >>>>>>>>>>>>>>>>>>> admin client.
> > > > >>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>> On Mon, 10 Jun 2019 at 19:31, Matthias J. Sax <
> > > > >>>>>>>>>>>>>>> matthias@confluent.io
> > > > >>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>> wrote:
> > > > >>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>> Hmmm...
> > > > >>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>> So the new interface, returns an instance of a
> > class
> > > > >> that
> > > > >>>>>>>>>>>>>>>> implements
> > > > >>>>>>>>>>>>>>>>>> the
> > > > >>>>>>>>>>>>>>>>>>>> interface. This sounds a little bit like an
> > > > >> anti-pattern?
> > > > >>>>>>>>>>>>>>> Shouldn't
> > > > >>>>>>>>>>>>>>>>>>>> interfaces actually not know anything about
> > classes
> > > > >> that
> > > > >>>>>>>>>>>>>>> implement
> > > > >>>>>>>>>>>>>>>>> the
> > > > >>>>>>>>>>>>>>>>>>>> interface?
> > > > >>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>> -Matthias
> > > > >>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>> On 6/10/19 11:22 AM, Andy Coates wrote:
> > > > >>>>>>>>>>>>>>>>>>>>> `AdminClient` would be deprecated purely
> because
> > it
> > > > >> would
> > > > >>>>>>>> no
> > > > >>>>>>>>>>>>>>>> longer
> > > > >>>>>>>>>>>>>>>>>>> serve
> > > > >>>>>>>>>>>>>>>>>>>>> any purpose and would be virtually empty,
> getting
> > > > >> all of
> > > > >>>>>>>> its
> > > > >>>>>>>>>>>>>>>>>>>> implementation
> > > > >>>>>>>>>>>>>>>>>>>>> from the new interfar. It would be nice to
> remove
> > > > >> this
> > > > >>>>>>>> from the
> > > > >>>>>>>>>>>>>>>> API
> > > > >>>>>>>>>>>>>>>>>> at
> > > > >>>>>>>>>>>>>>>>>>>> the
> > > > >>>>>>>>>>>>>>>>>>>>> next major version bump, hence the need to
> > > deprecate.
> > > > >>>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>>> `AdminClient.create()` would return what it
> does
> > > > >> today,
> > > > >>>>>>>> (so
> > > > >>>>>>>>>>>>>>> not a
> > > > >>>>>>>>>>>>>>>>>>>> breaking
> > > > >>>>>>>>>>>>>>>>>>>>> change).
> > > > >>>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>>> On Tue, 4 Jun 2019 at 22:24, Ryanne Dolan <
> > > > >>>>>>>>>>>>>>> ryannedolan@gmail.com
> > > > >>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>> wrote:
> > > > >>>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>>>>> The existing `AdminClient` will be marked as
> > > > >> deprecated.
> > > > >>>>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>>>> What's the reasoning behind this? I'm fine
> with
> > > the
> > > > >> other
> > > > >>>>>>>>>>>>>>>> changes,
> > > > >>>>>>>>>>>>>>>>>> but
> > > > >>>>>>>>>>>>>>>>>>>>>> would prefer to keep the existing public API
> > > intact
> > > > >> if
> > > > >>>>>>>> it's
> > > > >>>>>>>>>>>>>>> not
> > > > >>>>>>>>>>>>>>>>>>> hurting
> > > > >>>>>>>>>>>>>>>>>>>>>> anything.
> > > > >>>>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>>>> Also, what will AdminClient.create() return?
> > Would
> > > > >> it be
> > > > >>>>>>>> a
> > > > >>>>>>>>>>>>>>>>> breaking
> > > > >>>>>>>>>>>>>>>>>>>> change?
> > > > >>>>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>>>> Ryanne
> > > > >>>>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>>>> On Tue, Jun 4, 2019, 11:17 AM Andy Coates <
> > > > >>>>>>>> andy@confluent.io>
> > > > >>>>>>>>>>>>>>>>>> wrote:
> > > > >>>>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>>>>> Hi folks
> > > > >>>>>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>>>>> As there's been no chatter on this KIP I'm
> > > > >> assuming it's
> > > > >>>>>>>>>>>>>>>>>>>> non-contentious,
> > > > >>>>>>>>>>>>>>>>>>>>>>> (or just boring), hence I'd like to call a
> vote
> > > for
> > > > >>>>>>>> KIP-476:
> > > > >>>>>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>
> > > > >>>>>>>>>>>
> > > > >>>>>>>>
> > > > >>>>>>
> > > > >>
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-476%3A+Add+Java+AdminClient+Interface
> > > > >>>>>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>>>>> Thanks,
> > > > >>>>>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>>>>> Andy
> > > > >>>>>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>
> > > > >>>>>>>>>>>>
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>>>
> > > > >>>>>>>>
> > > > >>>>>>>
> > > > >>>>>>
> > > > >>>>>>
> > > > >>>>>
> > > > >>>>
> > > > >>>>
> > > > >>>> Attachments:
> > > > >>>> * signature.asc
> > > > >>>
> > > > >>
> > > > >
> > > >
> > > >
> > >
> >
>

Re: [VOTE] KIP-476: Add Java AdminClient interface

Posted by Rajini Sivaram <ra...@gmail.com>.

+1 (binding)

Thanks for the KIP, Andy!

Regards,

Rajini


On Thu, Jul 11, 2019 at 1:18 PM Gwen Shapira <gw...@confluent.io> wrote:

> +1 (binding)
>
> Thank you for the improvement.
>
> On Thu, Jul 11, 2019, 3:53 AM Andy Coates <an...@confluent.io> wrote:
>
> > Hi All,
> >
> > So voting currently stands on:
> >
> > Binding:
> > +1 Matthias,
> > +1 Colin
> >
> > Non-binding:
> > +1  Thomas Becker
> > +1 Satish Guggana
> > +1 Ryan Dolan
> >
> > So we're still 1 binding vote short. :(
> >
> >
> > On Wed, 3 Jul 2019 at 23:08, Matthias J. Sax <ma...@confluent.io>
> > wrote:
> >
> > > Thanks for the details Colin and Andy.
> > >
> > > My indent was not to block the KIP, but it seems to be a fair question
> > > to ask.
> > >
> > > I talked to Ismael offline about it and understand his reasoning better
> > > now. If we don't deprecate `abstract AdminClient` class, it seems
> > > reasonable to not deprecate the corresponding factory methods either.
> > >
> > >
> > > +1 (binding) on the current proposal
> > >
> > >
> > >
> > > -Matthias
> > >
> > > On 7/3/19 5:03 AM, Andy Coates wrote:
> > > > Matthias,
> > > >
> > > > I was referring to platforms such as spark or flink that support
> > multiple
> > > > versions of the Kafka clients. Ismael mentioned this higher up on the
> > > > thread.
> > > >
> > > > I'd prefer this KIP didn't get held up over somewhat unrelated
> change,
> > > i.e.
> > > > should the factory method be on the interface or utility class.
> > Surely,
> > > > now would be a great time to change this if we wanted, but we can
> also
> > > > change this later if we need to.  In the interest of moving forward,
> > can
> > > I
> > > > propose we leave the factory methods as they are in the KIP?
> > > >
> > > > Thanks,
> > > >
> > > > Andy
> > > >
> > > > On Tue, 2 Jul 2019 at 17:14, Colin McCabe <cm...@apache.org>
> wrote:
> > > >
> > > >> On Tue, Jul 2, 2019, at 09:14, Colin McCabe wrote:
> > > >>> On Mon, Jul 1, 2019, at 23:30, Matthias J. Sax wrote:
> > > >>>> Not sure, if I understand the argument?
> > > >>>>
> > > >>>> Why would anyone need to support multiple client side versions?
> > > >>>> Clients/brokers are forward/backward compatible anyway.
> > > >>>
> > > >>> When you're using many different libraries, it is helpful if they
> > don't
> > > >>> impose tight constraints on what versions their dependencies are.
> > > >>> Otherwise you can easily get in a situation where the constraints
> > can't
> > > >>> be satisfied.
> > > >>>
> > > >>>>
> > > >>>> Also, if one really supports multiple client side versions, won't
> > they
> > > >>>> use multiple shaded dependencies for different versions?
> > > >>>
> > > >>> Shading the Kafka client doesn't really work, because of how we use
> > > >> reflection.
> > > >>>
> > > >>>>
> > > >>>> Last, it's possible to suppress warnings (at least in Java).
> > > >>>
> > > >>> But not in Scala.  So that does not help (for example), Scala
> users.
> > > >>
> > > >> I meant to write "Spark users" here.
> > > >>
> > > >> C.
> > > >>
> > > >>>
> > > >>> I agree that in general we should be using deprecation when
> > > >>> appropriate, regardless of the potential annoyances to users.  But
> > I'm
> > > >>> not sure deprecating this method is really worth it.
> > > >>>
> > > >>> best,
> > > >>> Colin
> > > >>>
> > > >>>
> > > >>>>
> > > >>>> Can you elaborate?
> > > >>>>
> > > >>>> IMHO, just adding a statement to JavaDocs is a little weak, and at
> > > some
> > > >>>> point, we need to deprecate those methods anyway if we ever want
> to
> > > >>>> remove them. The earlier we deprecate them, the earlier we can
> > remove
> > > >> them.
> > > >>>>
> > > >>>>
> > > >>>> -Matthias
> > > >>>>
> > > >>>> On 7/1/19 4:22 AM, Andy Coates wrote:
> > > >>>>> Done. I've not deprecated the factory methods on the AdminClient
> > for
> > > >> the
> > > >>>>> same reason the AdminClient itself is not deprecated, i.e. this
> > > >> would cause
> > > >>>>> unavoidable warnings for libraries / platforms that support
> > multiple
> > > >>>>> versions of Kafka. However, I think we add a note to the Java
> docs
> > of
> > > >>>>> `AdminClient` to indicate that its use, going forward, is
> > > >> discouraged in
> > > >>>>> favour of the new `Admin` interface and explain why its not  been
> > > >>>>> deprecated, but that it may/will be removed in a future version.
> > > >>>>>
> > > >>>>> Regarding factory methods on interfaces: there seems to be some
> > > >> difference
> > > >>>>> of opinion here. I'm not sure of the best approach to revolve
> this.
> > > >> At the
> > > >>>>> moment the KIP has factory methods on the new `Admin` interface,
> > > >> rather
> > > >>>>> than some utility class. I prefer the utility class, but this
> isn't
> > > >> inline
> > > >>>>> with the patterns in the code base and some of the core team have
> > > >> expressed
> > > >>>>> they'd prefer to continue to have the factory methods on the
> > > >> interface.
> > > >>>>> I'm happy with this if others are.
> > > >>>>>
> > > >>>>> Thanks,
> > > >>>>>
> > > >>>>> Andy
> > > >>>>>
> > > >>>>> On Thu, 27 Jun 2019 at 23:21, Matthias J. Sax <
> > matthias@confluent.io
> > > >
> > > >> wrote:
> > > >>>>>
> > > >>>>>> @Andy:
> > > >>>>>>
> > > >>>>>> What about the factory methods of `AdminClient` class? Should
> they
> > > >> be
> > > >>>>>> deprecated?
> > > >>>>>>
> > > >>>>>> One nit about the KIP: can you maybe insert "code blocks" to
> > > >> highlight
> > > >>>>>> the API changes? Code blocks would simplify to read the KIP a
> lot.
> > > >>>>>>
> > > >>>>>>
> > > >>>>>> -Matthias
> > > >>>>>>
> > > >>>>>> On 6/26/19 6:56 AM, Ryanne Dolan wrote:
> > > >>>>>>> +1 (non-binding)
> > > >>>>>>>
> > > >>>>>>> Thanks.
> > > >>>>>>> Ryanne
> > > >>>>>>>
> > > >>>>>>> On Tue, Jun 25, 2019 at 10:21 PM Satish Duggana <
> > > >>>>>> satish.duggana@gmail.com>
> > > >>>>>>> wrote:
> > > >>>>>>>
> > > >>>>>>>> +1 (non-binding)
> > > >>>>>>>>
> > > >>>>>>>> On Wed, Jun 26, 2019 at 8:37 AM Satish Duggana <
> > > >>>>>> satish.duggana@gmail.com>
> > > >>>>>>>> wrote:
> > > >>>>>>>>>
> > > >>>>>>>>> +1 Matthias/Andy.
> > > >>>>>>>>> IMHO, interface is about the contract, it should not
> > have/expose
> > > >> any
> > > >>>>>>>>> implementation. I am fine with either way as it is more of
> > taste
> > > >> or
> > > >>>>>>>>> preference.
> > > >>>>>>>>>
> > > >>>>>>>>> Agree with Ismael/Colin/Ryanne on not deprecating for good
> > > >> reasons.
> > > >>>>>>>>>
> > > >>>>>>>>>
> > > >>>>>>>>> On Mon, Jun 24, 2019 at 8:33 PM Andy Coates <
> andy@confluent.io
> > >
> > > >> wrote:
> > > >>>>>>>>>>
> > > >>>>>>>>>> I agree Matthias.
> > > >>>>>>>>>>
> > > >>>>>>>>>> (In Scala, such factory methods are on a companion object.
> As
> > > >> Java
> > > >>>>>>>> doesn't
> > > >>>>>>>>>> have the concept of a companion object, an equivalent would
> > be a
> > > >>>>>>>> utility
> > > >>>>>>>>>> class with a similar name...)
> > > >>>>>>>>>>
> > > >>>>>>>>>> However, I'll update the KIP to include the factory method
> on
> > > >> the
> > > >>>>>>>> interface.
> > > >>>>>>>>>>
> > > >>>>>>>>>> On Fri, 21 Jun 2019 at 23:40, Matthias J. Sax <
> > > >> matthias@confluent.io>
> > > >>>>>>>> wrote:
> > > >>>>>>>>>>
> > > >>>>>>>>>>> I still think, that an interface does not need to know
> > > >> anything about
> > > >>>>>>>>>>> its implementation. But I am also fine if we add a factory
> > > >> method to
> > > >>>>>>>> the
> > > >>>>>>>>>>> new interface if that is preferred by most people.
> > > >>>>>>>>>>>
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> -Matthias
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> On 6/21/19 7:10 AM, Ismael Juma wrote:
> > > >>>>>>>>>>>> This is even more reason not to deprecate immediately,
> there
> > > >> is
> > > >>>>>>>> very
> > > >>>>>>>>>>> little
> > > >>>>>>>>>>>> maintenance cost for us. We should be mindful that many of
> > our
> > > >>>>>>>> users (eg
> > > >>>>>>>>>>>> Spark, Flink, etc.) typically allow users to specify the
> > kafka
> > > >>>>>>>> clients
> > > >>>>>>>>>>>> version and hence avoid using new classes/interfaces for
> > some
> > > >>>>>>>> time. They
> > > >>>>>>>>>>>> would get a bunch of warnings they cannot do anything
> about
> > > >> apart
> > > >>>>>>>> from
> > > >>>>>>>>>>>> suppressing.
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> Ismael
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> On Fri, Jun 21, 2019 at 4:00 AM Andy Coates <
> > > >> andy@confluent.io>
> > > >>>>>>>> wrote:
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>>> Hi Ismael,
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>> I’m happy enough to not deprecate the existing
> > `AdminClient`
> > > >>>>>>>> class as
> > > >>>>>>>>>>> part
> > > >>>>>>>>>>>>> of this change.
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>> However, note that, the class will likely be empty, i.e.
> > all
> > > >>>>>>>> methods and
> > > >>>>>>>>>>>>> implementations will be inherited from the interface:
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>> public abstract class AdminClient implements Admin {
> > > >>>>>>>>>>>>> }
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>> Not marking it as deprecated has the benefit that users
> > > >> won’t see
> > > >>>>>>>> any
> > > >>>>>>>>>>>>> deprecation warnings on the next release. Conversely,
> > > >> deprecating
> > > >>>>>>>> it
> > > >>>>>>>>>>> will
> > > >>>>>>>>>>>>> mean we can choose to remove this, now pointless class,
> in
> > > >> the
> > > >>>>>>>> future
> > > >>>>>>>>>>> if we
> > > >>>>>>>>>>>>> choose.
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>> That’s my thinking for deprecation, but as I’ve said I’m
> > > >> happy
> > > >>>>>>>> either
> > > >>>>>>>>>>> way.
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>> Andy
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>>> On 18 Jun 2019, at 16:09, Ismael Juma <
> ismael@juma.me.uk>
> > > >> wrote:
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>> I agree with Ryanne, I think we should avoid deprecating
> > > >>>>>>>> AdminClient
> > > >>>>>>>>>>> and
> > > >>>>>>>>>>>>>> causing so much churn for users who don't actually care
> > > >> about
> > > >>>>>>>> this
> > > >>>>>>>>>>> niche
> > > >>>>>>>>>>>>>> use case.
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>> Ismael
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>> On Tue, Jun 18, 2019 at 6:43 AM Andy Coates <
> > > >> andy@confluent.io>
> > > >>>>>>>> wrote:
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>> Hi Ryanne,
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>> If we don't change the client code, then everywhere
> will
> > > >> still
> > > >>>>>>>> expect
> > > >>>>>>>>>>>>>>> subclasses of `AdminClient`, so the interface will be
> of
> > no
> > > >>>>>>>> use, i.e.
> > > >>>>>>>>>>> I
> > > >>>>>>>>>>>>>>> can't write a class that implements the new interface
> and
> > > >> pass
> > > >>>>>>>> it to
> > > >>>>>>>>>>> the
> > > >>>>>>>>>>>>>>> client code.
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>> Thanks,
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>> Andy
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>> On Mon, 17 Jun 2019 at 19:01, Ryanne Dolan <
> > > >>>>>>>> ryannedolan@gmail.com>
> > > >>>>>>>>>>>>> wrote:
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> Andy, while I agree that the new interface is useful,
> > I'm
> > > >> not
> > > >>>>>>>>>>> convinced
> > > >>>>>>>>>>>>>>>> adding an interface requires deprecating AdminClient
> and
> > > >>>>>>>> changing so
> > > >>>>>>>>>>>>> much
> > > >>>>>>>>>>>>>>>> client code. Why not just add the Admin interface,
> have
> > > >>>>>>>> AdminClient
> > > >>>>>>>>>>>>>>>> implement it, and have done?
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> Ryanne
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> On Mon, Jun 17, 2019 at 12:09 PM Andy Coates <
> > > >>>>>>>> andy@confluent.io>
> > > >>>>>>>>>>>>> wrote:
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> Hi all,
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> I think I've addressed all concerns. Let me know if
> > I've
> > > >>>>>>>> not.  Can I
> > > >>>>>>>>>>>>>>> call
> > > >>>>>>>>>>>>>>>>> another round of votes please?
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> Thanks,
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> Andy
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> On Fri, 14 Jun 2019 at 04:55, Satish Duggana <
> > > >>>>>>>>>>>>> satish.duggana@gmail.com
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> wrote:
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>> Hi Andy,
> > > >>>>>>>>>>>>>>>>>> Thanks for the KIP. This is a good change and it
> gives
> > > >> the
> > > >>>>>>>> user a
> > > >>>>>>>>>>>>>>>> better
> > > >>>>>>>>>>>>>>>>>> handle on Admin client usage. I agree with the
> > proposal
> > > >>>>>>>> except the
> > > >>>>>>>>>>>>>>> new
> > > >>>>>>>>>>>>>>>>>> `Admin` interface having all the methods from
> > > >> `AdminClient`
> > > >>>>>>>>>>> abstract
> > > >>>>>>>>>>>>>>>>> class.
> > > >>>>>>>>>>>>>>>>>> It should be kept clean having only the admin
> > > >> operations as
> > > >>>>>>>> methods
> > > >>>>>>>>>>>>>>>> from
> > > >>>>>>>>>>>>>>>>>> KafkaClient abstract class but not the factory
> methods
> > > >> as
> > > >>>>>>>> mentioned
> > > >>>>>>>>>>>>>>> in
> > > >>>>>>>>>>>>>>>>> the
> > > >>>>>>>>>>>>>>>>>> earlier mail.
> > > >>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>> I know about dynamic proxies(which were widely used
> in
> > > >>>>>>>> RMI/EJB
> > > >>>>>>>>>>>>>>> world).
> > > >>>>>>>>>>>>>>>> I
> > > >>>>>>>>>>>>>>>>> am
> > > >>>>>>>>>>>>>>>>>> curious about the usecase using dynamic proxies with
> > > >> Admin
> > > >>>>>>>> client
> > > >>>>>>>>>>>>>>>>>> interface. Dynamic proxy can have performance
> penalty
> > > >> if it
> > > >>>>>>>> is used
> > > >>>>>>>>>>>>>>> in
> > > >>>>>>>>>>>>>>>>>> critical path. Is that the primary motivation for
> > > >> creating
> > > >>>>>>>> the KIP?
> > > >>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>> Thanks,
> > > >>>>>>>>>>>>>>>>>> Satish.
> > > >>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>> On Wed, Jun 12, 2019 at 8:43 PM Andy Coates <
> > > >>>>>>>> andy@confluent.io>
> > > >>>>>>>>>>>>>>> wrote:
> > > >>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>> I'm not married to that part.  That was only done
> to
> > > >> keep
> > > >>>>>>>> it more
> > > >>>>>>>>>>>>>>> or
> > > >>>>>>>>>>>>>>>>> less
> > > >>>>>>>>>>>>>>>>>>> inline with what's already there, (an abstract
> class
> > > >> that
> > > >>>>>>>> has a
> > > >>>>>>>>>>>>>>>> factory
> > > >>>>>>>>>>>>>>>>>>> method that returns a subclass.... sounds like the
> > same
> > > >>>>>>>>>>>>>>> anti-pattern
> > > >>>>>>>>>>>>>>>>> ;))
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>> An alternative would to have an `AdminClients`
> > utility
> > > >>>>>>>> class to
> > > >>>>>>>>>>>>>>>> create
> > > >>>>>>>>>>>>>>>>>> the
> > > >>>>>>>>>>>>>>>>>>> admin client.
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>> On Mon, 10 Jun 2019 at 19:31, Matthias J. Sax <
> > > >>>>>>>>>>>>>>> matthias@confluent.io
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>> wrote:
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>> Hmmm...
> > > >>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>> So the new interface, returns an instance of a
> class
> > > >> that
> > > >>>>>>>>>>>>>>>> implements
> > > >>>>>>>>>>>>>>>>>> the
> > > >>>>>>>>>>>>>>>>>>>> interface. This sounds a little bit like an
> > > >> anti-pattern?
> > > >>>>>>>>>>>>>>> Shouldn't
> > > >>>>>>>>>>>>>>>>>>>> interfaces actually not know anything about
> classes
> > > >> that
> > > >>>>>>>>>>>>>>> implement
> > > >>>>>>>>>>>>>>>>> the
> > > >>>>>>>>>>>>>>>>>>>> interface?
> > > >>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>> -Matthias
> > > >>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>> On 6/10/19 11:22 AM, Andy Coates wrote:
> > > >>>>>>>>>>>>>>>>>>>>> `AdminClient` would be deprecated purely because
> it
> > > >> would
> > > >>>>>>>> no
> > > >>>>>>>>>>>>>>>> longer
> > > >>>>>>>>>>>>>>>>>>> serve
> > > >>>>>>>>>>>>>>>>>>>>> any purpose and would be virtually empty, getting
> > > >> all of
> > > >>>>>>>> its
> > > >>>>>>>>>>>>>>>>>>>> implementation
> > > >>>>>>>>>>>>>>>>>>>>> from the new interfar. It would be nice to remove
> > > >> this
> > > >>>>>>>> from the
> > > >>>>>>>>>>>>>>>> API
> > > >>>>>>>>>>>>>>>>>> at
> > > >>>>>>>>>>>>>>>>>>>> the
> > > >>>>>>>>>>>>>>>>>>>>> next major version bump, hence the need to
> > deprecate.
> > > >>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>> `AdminClient.create()` would return what it does
> > > >> today,
> > > >>>>>>>> (so
> > > >>>>>>>>>>>>>>> not a
> > > >>>>>>>>>>>>>>>>>>>> breaking
> > > >>>>>>>>>>>>>>>>>>>>> change).
> > > >>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>> On Tue, 4 Jun 2019 at 22:24, Ryanne Dolan <
> > > >>>>>>>>>>>>>>> ryannedolan@gmail.com
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>> wrote:
> > > >>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>> The existing `AdminClient` will be marked as
> > > >> deprecated.
> > > >>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>> What's the reasoning behind this? I'm fine with
> > the
> > > >> other
> > > >>>>>>>>>>>>>>>> changes,
> > > >>>>>>>>>>>>>>>>>> but
> > > >>>>>>>>>>>>>>>>>>>>>> would prefer to keep the existing public API
> > intact
> > > >> if
> > > >>>>>>>> it's
> > > >>>>>>>>>>>>>>> not
> > > >>>>>>>>>>>>>>>>>>> hurting
> > > >>>>>>>>>>>>>>>>>>>>>> anything.
> > > >>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>> Also, what will AdminClient.create() return?
> Would
> > > >> it be
> > > >>>>>>>> a
> > > >>>>>>>>>>>>>>>>> breaking
> > > >>>>>>>>>>>>>>>>>>>> change?
> > > >>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>> Ryanne
> > > >>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>> On Tue, Jun 4, 2019, 11:17 AM Andy Coates <
> > > >>>>>>>> andy@confluent.io>
> > > >>>>>>>>>>>>>>>>>> wrote:
> > > >>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>> Hi folks
> > > >>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>> As there's been no chatter on this KIP I'm
> > > >> assuming it's
> > > >>>>>>>>>>>>>>>>>>>> non-contentious,
> > > >>>>>>>>>>>>>>>>>>>>>>> (or just boring), hence I'd like to call a vote
> > for
> > > >>>>>>>> KIP-476:
> > > >>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>
> > > >>>>>>>>
> > > >>>>>>
> > > >>
> > >
> >
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-476%3A+Add+Java+AdminClient+Interface
> > > >>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>> Thanks,
> > > >>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>> Andy
> > > >>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>
> > > >>>>>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>
> > > >>>>>>
> > > >>>>>>
> > > >>>>>
> > > >>>>
> > > >>>>
> > > >>>> Attachments:
> > > >>>> * signature.asc
> > > >>>
> > > >>
> > > >
> > >
> > >
> >
>

Re: [VOTE] KIP-476: Add Java AdminClient interface

Posted by Gwen Shapira <gw...@confluent.io>.

+1 (binding)

Thank you for the improvement.

On Thu, Jul 11, 2019, 3:53 AM Andy Coates <an...@confluent.io> wrote:

> Hi All,
>
> So voting currently stands on:
>
> Binding:
> +1 Matthias,
> +1 Colin
>
> Non-binding:
> +1  Thomas Becker
> +1 Satish Guggana
> +1 Ryan Dolan
>
> So we're still 1 binding vote short. :(
>
>
> On Wed, 3 Jul 2019 at 23:08, Matthias J. Sax <ma...@confluent.io>
> wrote:
>
> > Thanks for the details Colin and Andy.
> >
> > My indent was not to block the KIP, but it seems to be a fair question
> > to ask.
> >
> > I talked to Ismael offline about it and understand his reasoning better
> > now. If we don't deprecate `abstract AdminClient` class, it seems
> > reasonable to not deprecate the corresponding factory methods either.
> >
> >
> > +1 (binding) on the current proposal
> >
> >
> >
> > -Matthias
> >
> > On 7/3/19 5:03 AM, Andy Coates wrote:
> > > Matthias,
> > >
> > > I was referring to platforms such as spark or flink that support
> multiple
> > > versions of the Kafka clients. Ismael mentioned this higher up on the
> > > thread.
> > >
> > > I'd prefer this KIP didn't get held up over somewhat unrelated change,
> > i.e.
> > > should the factory method be on the interface or utility class.
> Surely,
> > > now would be a great time to change this if we wanted, but we can also
> > > change this later if we need to.  In the interest of moving forward,
> can
> > I
> > > propose we leave the factory methods as they are in the KIP?
> > >
> > > Thanks,
> > >
> > > Andy
> > >
> > > On Tue, 2 Jul 2019 at 17:14, Colin McCabe <cm...@apache.org> wrote:
> > >
> > >> On Tue, Jul 2, 2019, at 09:14, Colin McCabe wrote:
> > >>> On Mon, Jul 1, 2019, at 23:30, Matthias J. Sax wrote:
> > >>>> Not sure, if I understand the argument?
> > >>>>
> > >>>> Why would anyone need to support multiple client side versions?
> > >>>> Clients/brokers are forward/backward compatible anyway.
> > >>>
> > >>> When you're using many different libraries, it is helpful if they
> don't
> > >>> impose tight constraints on what versions their dependencies are.
> > >>> Otherwise you can easily get in a situation where the constraints
> can't
> > >>> be satisfied.
> > >>>
> > >>>>
> > >>>> Also, if one really supports multiple client side versions, won't
> they
> > >>>> use multiple shaded dependencies for different versions?
> > >>>
> > >>> Shading the Kafka client doesn't really work, because of how we use
> > >> reflection.
> > >>>
> > >>>>
> > >>>> Last, it's possible to suppress warnings (at least in Java).
> > >>>
> > >>> But not in Scala.  So that does not help (for example), Scala users.
> > >>
> > >> I meant to write "Spark users" here.
> > >>
> > >> C.
> > >>
> > >>>
> > >>> I agree that in general we should be using deprecation when
> > >>> appropriate, regardless of the potential annoyances to users.  But
> I'm
> > >>> not sure deprecating this method is really worth it.
> > >>>
> > >>> best,
> > >>> Colin
> > >>>
> > >>>
> > >>>>
> > >>>> Can you elaborate?
> > >>>>
> > >>>> IMHO, just adding a statement to JavaDocs is a little weak, and at
> > some
> > >>>> point, we need to deprecate those methods anyway if we ever want to
> > >>>> remove them. The earlier we deprecate them, the earlier we can
> remove
> > >> them.
> > >>>>
> > >>>>
> > >>>> -Matthias
> > >>>>
> > >>>> On 7/1/19 4:22 AM, Andy Coates wrote:
> > >>>>> Done. I've not deprecated the factory methods on the AdminClient
> for
> > >> the
> > >>>>> same reason the AdminClient itself is not deprecated, i.e. this
> > >> would cause
> > >>>>> unavoidable warnings for libraries / platforms that support
> multiple
> > >>>>> versions of Kafka. However, I think we add a note to the Java docs
> of
> > >>>>> `AdminClient` to indicate that its use, going forward, is
> > >> discouraged in
> > >>>>> favour of the new `Admin` interface and explain why its not  been
> > >>>>> deprecated, but that it may/will be removed in a future version.
> > >>>>>
> > >>>>> Regarding factory methods on interfaces: there seems to be some
> > >> difference
> > >>>>> of opinion here. I'm not sure of the best approach to revolve this.
> > >> At the
> > >>>>> moment the KIP has factory methods on the new `Admin` interface,
> > >> rather
> > >>>>> than some utility class. I prefer the utility class, but this isn't
> > >> inline
> > >>>>> with the patterns in the code base and some of the core team have
> > >> expressed
> > >>>>> they'd prefer to continue to have the factory methods on the
> > >> interface.
> > >>>>> I'm happy with this if others are.
> > >>>>>
> > >>>>> Thanks,
> > >>>>>
> > >>>>> Andy
> > >>>>>
> > >>>>> On Thu, 27 Jun 2019 at 23:21, Matthias J. Sax <
> matthias@confluent.io
> > >
> > >> wrote:
> > >>>>>
> > >>>>>> @Andy:
> > >>>>>>
> > >>>>>> What about the factory methods of `AdminClient` class? Should they
> > >> be
> > >>>>>> deprecated?
> > >>>>>>
> > >>>>>> One nit about the KIP: can you maybe insert "code blocks" to
> > >> highlight
> > >>>>>> the API changes? Code blocks would simplify to read the KIP a lot.
> > >>>>>>
> > >>>>>>
> > >>>>>> -Matthias
> > >>>>>>
> > >>>>>> On 6/26/19 6:56 AM, Ryanne Dolan wrote:
> > >>>>>>> +1 (non-binding)
> > >>>>>>>
> > >>>>>>> Thanks.
> > >>>>>>> Ryanne
> > >>>>>>>
> > >>>>>>> On Tue, Jun 25, 2019 at 10:21 PM Satish Duggana <
> > >>>>>> satish.duggana@gmail.com>
> > >>>>>>> wrote:
> > >>>>>>>
> > >>>>>>>> +1 (non-binding)
> > >>>>>>>>
> > >>>>>>>> On Wed, Jun 26, 2019 at 8:37 AM Satish Duggana <
> > >>>>>> satish.duggana@gmail.com>
> > >>>>>>>> wrote:
> > >>>>>>>>>
> > >>>>>>>>> +1 Matthias/Andy.
> > >>>>>>>>> IMHO, interface is about the contract, it should not
> have/expose
> > >> any
> > >>>>>>>>> implementation. I am fine with either way as it is more of
> taste
> > >> or
> > >>>>>>>>> preference.
> > >>>>>>>>>
> > >>>>>>>>> Agree with Ismael/Colin/Ryanne on not deprecating for good
> > >> reasons.
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>> On Mon, Jun 24, 2019 at 8:33 PM Andy Coates <andy@confluent.io
> >
> > >> wrote:
> > >>>>>>>>>>
> > >>>>>>>>>> I agree Matthias.
> > >>>>>>>>>>
> > >>>>>>>>>> (In Scala, such factory methods are on a companion object. As
> > >> Java
> > >>>>>>>> doesn't
> > >>>>>>>>>> have the concept of a companion object, an equivalent would
> be a
> > >>>>>>>> utility
> > >>>>>>>>>> class with a similar name...)
> > >>>>>>>>>>
> > >>>>>>>>>> However, I'll update the KIP to include the factory method on
> > >> the
> > >>>>>>>> interface.
> > >>>>>>>>>>
> > >>>>>>>>>> On Fri, 21 Jun 2019 at 23:40, Matthias J. Sax <
> > >> matthias@confluent.io>
> > >>>>>>>> wrote:
> > >>>>>>>>>>
> > >>>>>>>>>>> I still think, that an interface does not need to know
> > >> anything about
> > >>>>>>>>>>> its implementation. But I am also fine if we add a factory
> > >> method to
> > >>>>>>>> the
> > >>>>>>>>>>> new interface if that is preferred by most people.
> > >>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>>> -Matthias
> > >>>>>>>>>>>
> > >>>>>>>>>>> On 6/21/19 7:10 AM, Ismael Juma wrote:
> > >>>>>>>>>>>> This is even more reason not to deprecate immediately, there
> > >> is
> > >>>>>>>> very
> > >>>>>>>>>>> little
> > >>>>>>>>>>>> maintenance cost for us. We should be mindful that many of
> our
> > >>>>>>>> users (eg
> > >>>>>>>>>>>> Spark, Flink, etc.) typically allow users to specify the
> kafka
> > >>>>>>>> clients
> > >>>>>>>>>>>> version and hence avoid using new classes/interfaces for
> some
> > >>>>>>>> time. They
> > >>>>>>>>>>>> would get a bunch of warnings they cannot do anything about
> > >> apart
> > >>>>>>>> from
> > >>>>>>>>>>>> suppressing.
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> Ismael
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> On Fri, Jun 21, 2019 at 4:00 AM Andy Coates <
> > >> andy@confluent.io>
> > >>>>>>>> wrote:
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>> Hi Ismael,
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> I’m happy enough to not deprecate the existing
> `AdminClient`
> > >>>>>>>> class as
> > >>>>>>>>>>> part
> > >>>>>>>>>>>>> of this change.
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> However, note that, the class will likely be empty, i.e.
> all
> > >>>>>>>> methods and
> > >>>>>>>>>>>>> implementations will be inherited from the interface:
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> public abstract class AdminClient implements Admin {
> > >>>>>>>>>>>>> }
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> Not marking it as deprecated has the benefit that users
> > >> won’t see
> > >>>>>>>> any
> > >>>>>>>>>>>>> deprecation warnings on the next release. Conversely,
> > >> deprecating
> > >>>>>>>> it
> > >>>>>>>>>>> will
> > >>>>>>>>>>>>> mean we can choose to remove this, now pointless class, in
> > >> the
> > >>>>>>>> future
> > >>>>>>>>>>> if we
> > >>>>>>>>>>>>> choose.
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> That’s my thinking for deprecation, but as I’ve said I’m
> > >> happy
> > >>>>>>>> either
> > >>>>>>>>>>> way.
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> Andy
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>> On 18 Jun 2019, at 16:09, Ismael Juma <is...@juma.me.uk>
> > >> wrote:
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>> I agree with Ryanne, I think we should avoid deprecating
> > >>>>>>>> AdminClient
> > >>>>>>>>>>> and
> > >>>>>>>>>>>>>> causing so much churn for users who don't actually care
> > >> about
> > >>>>>>>> this
> > >>>>>>>>>>> niche
> > >>>>>>>>>>>>>> use case.
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>> Ismael
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>> On Tue, Jun 18, 2019 at 6:43 AM Andy Coates <
> > >> andy@confluent.io>
> > >>>>>>>> wrote:
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> Hi Ryanne,
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> If we don't change the client code, then everywhere will
> > >> still
> > >>>>>>>> expect
> > >>>>>>>>>>>>>>> subclasses of `AdminClient`, so the interface will be of
> no
> > >>>>>>>> use, i.e.
> > >>>>>>>>>>> I
> > >>>>>>>>>>>>>>> can't write a class that implements the new interface and
> > >> pass
> > >>>>>>>> it to
> > >>>>>>>>>>> the
> > >>>>>>>>>>>>>>> client code.
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> Thanks,
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> Andy
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> On Mon, 17 Jun 2019 at 19:01, Ryanne Dolan <
> > >>>>>>>> ryannedolan@gmail.com>
> > >>>>>>>>>>>>> wrote:
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> Andy, while I agree that the new interface is useful,
> I'm
> > >> not
> > >>>>>>>>>>> convinced
> > >>>>>>>>>>>>>>>> adding an interface requires deprecating AdminClient and
> > >>>>>>>> changing so
> > >>>>>>>>>>>>> much
> > >>>>>>>>>>>>>>>> client code. Why not just add the Admin interface, have
> > >>>>>>>> AdminClient
> > >>>>>>>>>>>>>>>> implement it, and have done?
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> Ryanne
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> On Mon, Jun 17, 2019 at 12:09 PM Andy Coates <
> > >>>>>>>> andy@confluent.io>
> > >>>>>>>>>>>>> wrote:
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> Hi all,
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> I think I've addressed all concerns. Let me know if
> I've
> > >>>>>>>> not.  Can I
> > >>>>>>>>>>>>>>> call
> > >>>>>>>>>>>>>>>>> another round of votes please?
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> Thanks,
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> Andy
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> On Fri, 14 Jun 2019 at 04:55, Satish Duggana <
> > >>>>>>>>>>>>> satish.duggana@gmail.com
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> wrote:
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>> Hi Andy,
> > >>>>>>>>>>>>>>>>>> Thanks for the KIP. This is a good change and it gives
> > >> the
> > >>>>>>>> user a
> > >>>>>>>>>>>>>>>> better
> > >>>>>>>>>>>>>>>>>> handle on Admin client usage. I agree with the
> proposal
> > >>>>>>>> except the
> > >>>>>>>>>>>>>>> new
> > >>>>>>>>>>>>>>>>>> `Admin` interface having all the methods from
> > >> `AdminClient`
> > >>>>>>>>>>> abstract
> > >>>>>>>>>>>>>>>>> class.
> > >>>>>>>>>>>>>>>>>> It should be kept clean having only the admin
> > >> operations as
> > >>>>>>>> methods
> > >>>>>>>>>>>>>>>> from
> > >>>>>>>>>>>>>>>>>> KafkaClient abstract class but not the factory methods
> > >> as
> > >>>>>>>> mentioned
> > >>>>>>>>>>>>>>> in
> > >>>>>>>>>>>>>>>>> the
> > >>>>>>>>>>>>>>>>>> earlier mail.
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>> I know about dynamic proxies(which were widely used in
> > >>>>>>>> RMI/EJB
> > >>>>>>>>>>>>>>> world).
> > >>>>>>>>>>>>>>>> I
> > >>>>>>>>>>>>>>>>> am
> > >>>>>>>>>>>>>>>>>> curious about the usecase using dynamic proxies with
> > >> Admin
> > >>>>>>>> client
> > >>>>>>>>>>>>>>>>>> interface. Dynamic proxy can have performance penalty
> > >> if it
> > >>>>>>>> is used
> > >>>>>>>>>>>>>>> in
> > >>>>>>>>>>>>>>>>>> critical path. Is that the primary motivation for
> > >> creating
> > >>>>>>>> the KIP?
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>> Thanks,
> > >>>>>>>>>>>>>>>>>> Satish.
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>> On Wed, Jun 12, 2019 at 8:43 PM Andy Coates <
> > >>>>>>>> andy@confluent.io>
> > >>>>>>>>>>>>>>> wrote:
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>> I'm not married to that part.  That was only done to
> > >> keep
> > >>>>>>>> it more
> > >>>>>>>>>>>>>>> or
> > >>>>>>>>>>>>>>>>> less
> > >>>>>>>>>>>>>>>>>>> inline with what's already there, (an abstract class
> > >> that
> > >>>>>>>> has a
> > >>>>>>>>>>>>>>>> factory
> > >>>>>>>>>>>>>>>>>>> method that returns a subclass.... sounds like the
> same
> > >>>>>>>>>>>>>>> anti-pattern
> > >>>>>>>>>>>>>>>>> ;))
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>> An alternative would to have an `AdminClients`
> utility
> > >>>>>>>> class to
> > >>>>>>>>>>>>>>>> create
> > >>>>>>>>>>>>>>>>>> the
> > >>>>>>>>>>>>>>>>>>> admin client.
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>> On Mon, 10 Jun 2019 at 19:31, Matthias J. Sax <
> > >>>>>>>>>>>>>>> matthias@confluent.io
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>> wrote:
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>> Hmmm...
> > >>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>> So the new interface, returns an instance of a class
> > >> that
> > >>>>>>>>>>>>>>>> implements
> > >>>>>>>>>>>>>>>>>> the
> > >>>>>>>>>>>>>>>>>>>> interface. This sounds a little bit like an
> > >> anti-pattern?
> > >>>>>>>>>>>>>>> Shouldn't
> > >>>>>>>>>>>>>>>>>>>> interfaces actually not know anything about classes
> > >> that
> > >>>>>>>>>>>>>>> implement
> > >>>>>>>>>>>>>>>>> the
> > >>>>>>>>>>>>>>>>>>>> interface?
> > >>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>> -Matthias
> > >>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>> On 6/10/19 11:22 AM, Andy Coates wrote:
> > >>>>>>>>>>>>>>>>>>>>> `AdminClient` would be deprecated purely because it
> > >> would
> > >>>>>>>> no
> > >>>>>>>>>>>>>>>> longer
> > >>>>>>>>>>>>>>>>>>> serve
> > >>>>>>>>>>>>>>>>>>>>> any purpose and would be virtually empty, getting
> > >> all of
> > >>>>>>>> its
> > >>>>>>>>>>>>>>>>>>>> implementation
> > >>>>>>>>>>>>>>>>>>>>> from the new interfar. It would be nice to remove
> > >> this
> > >>>>>>>> from the
> > >>>>>>>>>>>>>>>> API
> > >>>>>>>>>>>>>>>>>> at
> > >>>>>>>>>>>>>>>>>>>> the
> > >>>>>>>>>>>>>>>>>>>>> next major version bump, hence the need to
> deprecate.
> > >>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>> `AdminClient.create()` would return what it does
> > >> today,
> > >>>>>>>> (so
> > >>>>>>>>>>>>>>> not a
> > >>>>>>>>>>>>>>>>>>>> breaking
> > >>>>>>>>>>>>>>>>>>>>> change).
> > >>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>> On Tue, 4 Jun 2019 at 22:24, Ryanne Dolan <
> > >>>>>>>>>>>>>>> ryannedolan@gmail.com
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>> wrote:
> > >>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>> The existing `AdminClient` will be marked as
> > >> deprecated.
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>> What's the reasoning behind this? I'm fine with
> the
> > >> other
> > >>>>>>>>>>>>>>>> changes,
> > >>>>>>>>>>>>>>>>>> but
> > >>>>>>>>>>>>>>>>>>>>>> would prefer to keep the existing public API
> intact
> > >> if
> > >>>>>>>> it's
> > >>>>>>>>>>>>>>> not
> > >>>>>>>>>>>>>>>>>>> hurting
> > >>>>>>>>>>>>>>>>>>>>>> anything.
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>> Also, what will AdminClient.create() return? Would
> > >> it be
> > >>>>>>>> a
> > >>>>>>>>>>>>>>>>> breaking
> > >>>>>>>>>>>>>>>>>>>> change?
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>> Ryanne
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>> On Tue, Jun 4, 2019, 11:17 AM Andy Coates <
> > >>>>>>>> andy@confluent.io>
> > >>>>>>>>>>>>>>>>>> wrote:
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>> Hi folks
> > >>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>> As there's been no chatter on this KIP I'm
> > >> assuming it's
> > >>>>>>>>>>>>>>>>>>>> non-contentious,
> > >>>>>>>>>>>>>>>>>>>>>>> (or just boring), hence I'd like to call a vote
> for
> > >>>>>>>> KIP-476:
> > >>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>
> > >>>>>>
> > >>
> >
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-476%3A+Add+Java+AdminClient+Interface
> > >>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>> Thanks,
> > >>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>> Andy
> > >>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>
> > >>>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>
> > >>>>
> > >>>>
> > >>>> Attachments:
> > >>>> * signature.asc
> > >>>
> > >>
> > >
> >
> >
>

Re: [VOTE] KIP-476: Add Java AdminClient interface

Posted by Andy Coates <an...@confluent.io>.

Hi All,

So voting currently stands on:

Binding:
+1 Matthias,
+1 Colin

Non-binding:
+1  Thomas Becker
+1 Satish Guggana
+1 Ryan Dolan

So we're still 1 binding vote short. :(


On Wed, 3 Jul 2019 at 23:08, Matthias J. Sax <ma...@confluent.io> wrote:

> Thanks for the details Colin and Andy.
>
> My indent was not to block the KIP, but it seems to be a fair question
> to ask.
>
> I talked to Ismael offline about it and understand his reasoning better
> now. If we don't deprecate `abstract AdminClient` class, it seems
> reasonable to not deprecate the corresponding factory methods either.
>
>
> +1 (binding) on the current proposal
>
>
>
> -Matthias
>
> On 7/3/19 5:03 AM, Andy Coates wrote:
> > Matthias,
> >
> > I was referring to platforms such as spark or flink that support multiple
> > versions of the Kafka clients. Ismael mentioned this higher up on the
> > thread.
> >
> > I'd prefer this KIP didn't get held up over somewhat unrelated change,
> i.e.
> > should the factory method be on the interface or utility class.  Surely,
> > now would be a great time to change this if we wanted, but we can also
> > change this later if we need to.  In the interest of moving forward, can
> I
> > propose we leave the factory methods as they are in the KIP?
> >
> > Thanks,
> >
> > Andy
> >
> > On Tue, 2 Jul 2019 at 17:14, Colin McCabe <cm...@apache.org> wrote:
> >
> >> On Tue, Jul 2, 2019, at 09:14, Colin McCabe wrote:
> >>> On Mon, Jul 1, 2019, at 23:30, Matthias J. Sax wrote:
> >>>> Not sure, if I understand the argument?
> >>>>
> >>>> Why would anyone need to support multiple client side versions?
> >>>> Clients/brokers are forward/backward compatible anyway.
> >>>
> >>> When you're using many different libraries, it is helpful if they don't
> >>> impose tight constraints on what versions their dependencies are.
> >>> Otherwise you can easily get in a situation where the constraints can't
> >>> be satisfied.
> >>>
> >>>>
> >>>> Also, if one really supports multiple client side versions, won't they
> >>>> use multiple shaded dependencies for different versions?
> >>>
> >>> Shading the Kafka client doesn't really work, because of how we use
> >> reflection.
> >>>
> >>>>
> >>>> Last, it's possible to suppress warnings (at least in Java).
> >>>
> >>> But not in Scala.  So that does not help (for example), Scala users.
> >>
> >> I meant to write "Spark users" here.
> >>
> >> C.
> >>
> >>>
> >>> I agree that in general we should be using deprecation when
> >>> appropriate, regardless of the potential annoyances to users.  But I'm
> >>> not sure deprecating this method is really worth it.
> >>>
> >>> best,
> >>> Colin
> >>>
> >>>
> >>>>
> >>>> Can you elaborate?
> >>>>
> >>>> IMHO, just adding a statement to JavaDocs is a little weak, and at
> some
> >>>> point, we need to deprecate those methods anyway if we ever want to
> >>>> remove them. The earlier we deprecate them, the earlier we can remove
> >> them.
> >>>>
> >>>>
> >>>> -Matthias
> >>>>
> >>>> On 7/1/19 4:22 AM, Andy Coates wrote:
> >>>>> Done. I've not deprecated the factory methods on the AdminClient for
> >> the
> >>>>> same reason the AdminClient itself is not deprecated, i.e. this
> >> would cause
> >>>>> unavoidable warnings for libraries / platforms that support multiple
> >>>>> versions of Kafka. However, I think we add a note to the Java docs of
> >>>>> `AdminClient` to indicate that its use, going forward, is
> >> discouraged in
> >>>>> favour of the new `Admin` interface and explain why its not  been
> >>>>> deprecated, but that it may/will be removed in a future version.
> >>>>>
> >>>>> Regarding factory methods on interfaces: there seems to be some
> >> difference
> >>>>> of opinion here. I'm not sure of the best approach to revolve this.
> >> At the
> >>>>> moment the KIP has factory methods on the new `Admin` interface,
> >> rather
> >>>>> than some utility class. I prefer the utility class, but this isn't
> >> inline
> >>>>> with the patterns in the code base and some of the core team have
> >> expressed
> >>>>> they'd prefer to continue to have the factory methods on the
> >> interface.
> >>>>> I'm happy with this if others are.
> >>>>>
> >>>>> Thanks,
> >>>>>
> >>>>> Andy
> >>>>>
> >>>>> On Thu, 27 Jun 2019 at 23:21, Matthias J. Sax <matthias@confluent.io
> >
> >> wrote:
> >>>>>
> >>>>>> @Andy:
> >>>>>>
> >>>>>> What about the factory methods of `AdminClient` class? Should they
> >> be
> >>>>>> deprecated?
> >>>>>>
> >>>>>> One nit about the KIP: can you maybe insert "code blocks" to
> >> highlight
> >>>>>> the API changes? Code blocks would simplify to read the KIP a lot.
> >>>>>>
> >>>>>>
> >>>>>> -Matthias
> >>>>>>
> >>>>>> On 6/26/19 6:56 AM, Ryanne Dolan wrote:
> >>>>>>> +1 (non-binding)
> >>>>>>>
> >>>>>>> Thanks.
> >>>>>>> Ryanne
> >>>>>>>
> >>>>>>> On Tue, Jun 25, 2019 at 10:21 PM Satish Duggana <
> >>>>>> satish.duggana@gmail.com>
> >>>>>>> wrote:
> >>>>>>>
> >>>>>>>> +1 (non-binding)
> >>>>>>>>
> >>>>>>>> On Wed, Jun 26, 2019 at 8:37 AM Satish Duggana <
> >>>>>> satish.duggana@gmail.com>
> >>>>>>>> wrote:
> >>>>>>>>>
> >>>>>>>>> +1 Matthias/Andy.
> >>>>>>>>> IMHO, interface is about the contract, it should not have/expose
> >> any
> >>>>>>>>> implementation. I am fine with either way as it is more of taste
> >> or
> >>>>>>>>> preference.
> >>>>>>>>>
> >>>>>>>>> Agree with Ismael/Colin/Ryanne on not deprecating for good
> >> reasons.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> On Mon, Jun 24, 2019 at 8:33 PM Andy Coates <an...@confluent.io>
> >> wrote:
> >>>>>>>>>>
> >>>>>>>>>> I agree Matthias.
> >>>>>>>>>>
> >>>>>>>>>> (In Scala, such factory methods are on a companion object. As
> >> Java
> >>>>>>>> doesn't
> >>>>>>>>>> have the concept of a companion object, an equivalent would be a
> >>>>>>>> utility
> >>>>>>>>>> class with a similar name...)
> >>>>>>>>>>
> >>>>>>>>>> However, I'll update the KIP to include the factory method on
> >> the
> >>>>>>>> interface.
> >>>>>>>>>>
> >>>>>>>>>> On Fri, 21 Jun 2019 at 23:40, Matthias J. Sax <
> >> matthias@confluent.io>
> >>>>>>>> wrote:
> >>>>>>>>>>
> >>>>>>>>>>> I still think, that an interface does not need to know
> >> anything about
> >>>>>>>>>>> its implementation. But I am also fine if we add a factory
> >> method to
> >>>>>>>> the
> >>>>>>>>>>> new interface if that is preferred by most people.
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> -Matthias
> >>>>>>>>>>>
> >>>>>>>>>>> On 6/21/19 7:10 AM, Ismael Juma wrote:
> >>>>>>>>>>>> This is even more reason not to deprecate immediately, there
> >> is
> >>>>>>>> very
> >>>>>>>>>>> little
> >>>>>>>>>>>> maintenance cost for us. We should be mindful that many of our
> >>>>>>>> users (eg
> >>>>>>>>>>>> Spark, Flink, etc.) typically allow users to specify the kafka
> >>>>>>>> clients
> >>>>>>>>>>>> version and hence avoid using new classes/interfaces for some
> >>>>>>>> time. They
> >>>>>>>>>>>> would get a bunch of warnings they cannot do anything about
> >> apart
> >>>>>>>> from
> >>>>>>>>>>>> suppressing.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Ismael
> >>>>>>>>>>>>
> >>>>>>>>>>>> On Fri, Jun 21, 2019 at 4:00 AM Andy Coates <
> >> andy@confluent.io>
> >>>>>>>> wrote:
> >>>>>>>>>>>>
> >>>>>>>>>>>>> Hi Ismael,
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> I’m happy enough to not deprecate the existing `AdminClient`
> >>>>>>>> class as
> >>>>>>>>>>> part
> >>>>>>>>>>>>> of this change.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> However, note that, the class will likely be empty, i.e. all
> >>>>>>>> methods and
> >>>>>>>>>>>>> implementations will be inherited from the interface:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> public abstract class AdminClient implements Admin {
> >>>>>>>>>>>>> }
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Not marking it as deprecated has the benefit that users
> >> won’t see
> >>>>>>>> any
> >>>>>>>>>>>>> deprecation warnings on the next release. Conversely,
> >> deprecating
> >>>>>>>> it
> >>>>>>>>>>> will
> >>>>>>>>>>>>> mean we can choose to remove this, now pointless class, in
> >> the
> >>>>>>>> future
> >>>>>>>>>>> if we
> >>>>>>>>>>>>> choose.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> That’s my thinking for deprecation, but as I’ve said I’m
> >> happy
> >>>>>>>> either
> >>>>>>>>>>> way.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Andy
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> On 18 Jun 2019, at 16:09, Ismael Juma <is...@juma.me.uk>
> >> wrote:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> I agree with Ryanne, I think we should avoid deprecating
> >>>>>>>> AdminClient
> >>>>>>>>>>> and
> >>>>>>>>>>>>>> causing so much churn for users who don't actually care
> >> about
> >>>>>>>> this
> >>>>>>>>>>> niche
> >>>>>>>>>>>>>> use case.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Ismael
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> On Tue, Jun 18, 2019 at 6:43 AM Andy Coates <
> >> andy@confluent.io>
> >>>>>>>> wrote:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Hi Ryanne,
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> If we don't change the client code, then everywhere will
> >> still
> >>>>>>>> expect
> >>>>>>>>>>>>>>> subclasses of `AdminClient`, so the interface will be of no
> >>>>>>>> use, i.e.
> >>>>>>>>>>> I
> >>>>>>>>>>>>>>> can't write a class that implements the new interface and
> >> pass
> >>>>>>>> it to
> >>>>>>>>>>> the
> >>>>>>>>>>>>>>> client code.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Thanks,
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Andy
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> On Mon, 17 Jun 2019 at 19:01, Ryanne Dolan <
> >>>>>>>> ryannedolan@gmail.com>
> >>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Andy, while I agree that the new interface is useful, I'm
> >> not
> >>>>>>>>>>> convinced
> >>>>>>>>>>>>>>>> adding an interface requires deprecating AdminClient and
> >>>>>>>> changing so
> >>>>>>>>>>>>> much
> >>>>>>>>>>>>>>>> client code. Why not just add the Admin interface, have
> >>>>>>>> AdminClient
> >>>>>>>>>>>>>>>> implement it, and have done?
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Ryanne
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> On Mon, Jun 17, 2019 at 12:09 PM Andy Coates <
> >>>>>>>> andy@confluent.io>
> >>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Hi all,
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> I think I've addressed all concerns. Let me know if I've
> >>>>>>>> not.  Can I
> >>>>>>>>>>>>>>> call
> >>>>>>>>>>>>>>>>> another round of votes please?
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Thanks,
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Andy
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> On Fri, 14 Jun 2019 at 04:55, Satish Duggana <
> >>>>>>>>>>>>> satish.duggana@gmail.com
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Hi Andy,
> >>>>>>>>>>>>>>>>>> Thanks for the KIP. This is a good change and it gives
> >> the
> >>>>>>>> user a
> >>>>>>>>>>>>>>>> better
> >>>>>>>>>>>>>>>>>> handle on Admin client usage. I agree with the proposal
> >>>>>>>> except the
> >>>>>>>>>>>>>>> new
> >>>>>>>>>>>>>>>>>> `Admin` interface having all the methods from
> >> `AdminClient`
> >>>>>>>>>>> abstract
> >>>>>>>>>>>>>>>>> class.
> >>>>>>>>>>>>>>>>>> It should be kept clean having only the admin
> >> operations as
> >>>>>>>> methods
> >>>>>>>>>>>>>>>> from
> >>>>>>>>>>>>>>>>>> KafkaClient abstract class but not the factory methods
> >> as
> >>>>>>>> mentioned
> >>>>>>>>>>>>>>> in
> >>>>>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>> earlier mail.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> I know about dynamic proxies(which were widely used in
> >>>>>>>> RMI/EJB
> >>>>>>>>>>>>>>> world).
> >>>>>>>>>>>>>>>> I
> >>>>>>>>>>>>>>>>> am
> >>>>>>>>>>>>>>>>>> curious about the usecase using dynamic proxies with
> >> Admin
> >>>>>>>> client
> >>>>>>>>>>>>>>>>>> interface. Dynamic proxy can have performance penalty
> >> if it
> >>>>>>>> is used
> >>>>>>>>>>>>>>> in
> >>>>>>>>>>>>>>>>>> critical path. Is that the primary motivation for
> >> creating
> >>>>>>>> the KIP?
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Thanks,
> >>>>>>>>>>>>>>>>>> Satish.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> On Wed, Jun 12, 2019 at 8:43 PM Andy Coates <
> >>>>>>>> andy@confluent.io>
> >>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> I'm not married to that part.  That was only done to
> >> keep
> >>>>>>>> it more
> >>>>>>>>>>>>>>> or
> >>>>>>>>>>>>>>>>> less
> >>>>>>>>>>>>>>>>>>> inline with what's already there, (an abstract class
> >> that
> >>>>>>>> has a
> >>>>>>>>>>>>>>>> factory
> >>>>>>>>>>>>>>>>>>> method that returns a subclass.... sounds like the same
> >>>>>>>>>>>>>>> anti-pattern
> >>>>>>>>>>>>>>>>> ;))
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> An alternative would to have an `AdminClients` utility
> >>>>>>>> class to
> >>>>>>>>>>>>>>>> create
> >>>>>>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>> admin client.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> On Mon, 10 Jun 2019 at 19:31, Matthias J. Sax <
> >>>>>>>>>>>>>>> matthias@confluent.io
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> Hmmm...
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> So the new interface, returns an instance of a class
> >> that
> >>>>>>>>>>>>>>>> implements
> >>>>>>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>>> interface. This sounds a little bit like an
> >> anti-pattern?
> >>>>>>>>>>>>>>> Shouldn't
> >>>>>>>>>>>>>>>>>>>> interfaces actually not know anything about classes
> >> that
> >>>>>>>>>>>>>>> implement
> >>>>>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>>> interface?
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> -Matthias
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> On 6/10/19 11:22 AM, Andy Coates wrote:
> >>>>>>>>>>>>>>>>>>>>> `AdminClient` would be deprecated purely because it
> >> would
> >>>>>>>> no
> >>>>>>>>>>>>>>>> longer
> >>>>>>>>>>>>>>>>>>> serve
> >>>>>>>>>>>>>>>>>>>>> any purpose and would be virtually empty, getting
> >> all of
> >>>>>>>> its
> >>>>>>>>>>>>>>>>>>>> implementation
> >>>>>>>>>>>>>>>>>>>>> from the new interfar. It would be nice to remove
> >> this
> >>>>>>>> from the
> >>>>>>>>>>>>>>>> API
> >>>>>>>>>>>>>>>>>> at
> >>>>>>>>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>>>> next major version bump, hence the need to deprecate.
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> `AdminClient.create()` would return what it does
> >> today,
> >>>>>>>> (so
> >>>>>>>>>>>>>>> not a
> >>>>>>>>>>>>>>>>>>>> breaking
> >>>>>>>>>>>>>>>>>>>>> change).
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> On Tue, 4 Jun 2019 at 22:24, Ryanne Dolan <
> >>>>>>>>>>>>>>> ryannedolan@gmail.com
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> The existing `AdminClient` will be marked as
> >> deprecated.
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> What's the reasoning behind this? I'm fine with the
> >> other
> >>>>>>>>>>>>>>>> changes,
> >>>>>>>>>>>>>>>>>> but
> >>>>>>>>>>>>>>>>>>>>>> would prefer to keep the existing public API intact
> >> if
> >>>>>>>> it's
> >>>>>>>>>>>>>>> not
> >>>>>>>>>>>>>>>>>>> hurting
> >>>>>>>>>>>>>>>>>>>>>> anything.
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> Also, what will AdminClient.create() return? Would
> >> it be
> >>>>>>>> a
> >>>>>>>>>>>>>>>>> breaking
> >>>>>>>>>>>>>>>>>>>> change?
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> Ryanne
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> On Tue, Jun 4, 2019, 11:17 AM Andy Coates <
> >>>>>>>> andy@confluent.io>
> >>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> Hi folks
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> As there's been no chatter on this KIP I'm
> >> assuming it's
> >>>>>>>>>>>>>>>>>>>> non-contentious,
> >>>>>>>>>>>>>>>>>>>>>>> (or just boring), hence I'd like to call a vote for
> >>>>>>>> KIP-476:
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>
> >>>>>>
> >>
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-476%3A+Add+Java+AdminClient+Interface
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> Thanks,
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> Andy
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>>
> >>>> Attachments:
> >>>> * signature.asc
> >>>
> >>
> >
>
>

Re: [VOTE] KIP-476: Add Java AdminClient interface

Posted by "Matthias J. Sax" <ma...@confluent.io>.

Thanks for the details Colin and Andy.

My indent was not to block the KIP, but it seems to be a fair question
to ask.

I talked to Ismael offline about it and understand his reasoning better
now. If we don't deprecate `abstract AdminClient` class, it seems
reasonable to not deprecate the corresponding factory methods either.


+1 (binding) on the current proposal



-Matthias

On 7/3/19 5:03 AM, Andy Coates wrote:
> Matthias,
> 
> I was referring to platforms such as spark or flink that support multiple
> versions of the Kafka clients. Ismael mentioned this higher up on the
> thread.
> 
> I'd prefer this KIP didn't get held up over somewhat unrelated change, i.e.
> should the factory method be on the interface or utility class.  Surely,
> now would be a great time to change this if we wanted, but we can also
> change this later if we need to.  In the interest of moving forward, can I
> propose we leave the factory methods as they are in the KIP?
> 
> Thanks,
> 
> Andy
> 
> On Tue, 2 Jul 2019 at 17:14, Colin McCabe <cm...@apache.org> wrote:
> 
>> On Tue, Jul 2, 2019, at 09:14, Colin McCabe wrote:
>>> On Mon, Jul 1, 2019, at 23:30, Matthias J. Sax wrote:
>>>> Not sure, if I understand the argument?
>>>>
>>>> Why would anyone need to support multiple client side versions?
>>>> Clients/brokers are forward/backward compatible anyway.
>>>
>>> When you're using many different libraries, it is helpful if they don't
>>> impose tight constraints on what versions their dependencies are.
>>> Otherwise you can easily get in a situation where the constraints can't
>>> be satisfied.
>>>
>>>>
>>>> Also, if one really supports multiple client side versions, won't they
>>>> use multiple shaded dependencies for different versions?
>>>
>>> Shading the Kafka client doesn't really work, because of how we use
>> reflection.
>>>
>>>>
>>>> Last, it's possible to suppress warnings (at least in Java).
>>>
>>> But not in Scala.  So that does not help (for example), Scala users.
>>
>> I meant to write "Spark users" here.
>>
>> C.
>>
>>>
>>> I agree that in general we should be using deprecation when
>>> appropriate, regardless of the potential annoyances to users.  But I'm
>>> not sure deprecating this method is really worth it.
>>>
>>> best,
>>> Colin
>>>
>>>
>>>>
>>>> Can you elaborate?
>>>>
>>>> IMHO, just adding a statement to JavaDocs is a little weak, and at some
>>>> point, we need to deprecate those methods anyway if we ever want to
>>>> remove them. The earlier we deprecate them, the earlier we can remove
>> them.
>>>>
>>>>
>>>> -Matthias
>>>>
>>>> On 7/1/19 4:22 AM, Andy Coates wrote:
>>>>> Done. I've not deprecated the factory methods on the AdminClient for
>> the
>>>>> same reason the AdminClient itself is not deprecated, i.e. this
>> would cause
>>>>> unavoidable warnings for libraries / platforms that support multiple
>>>>> versions of Kafka. However, I think we add a note to the Java docs of
>>>>> `AdminClient` to indicate that its use, going forward, is
>> discouraged in
>>>>> favour of the new `Admin` interface and explain why its not  been
>>>>> deprecated, but that it may/will be removed in a future version.
>>>>>
>>>>> Regarding factory methods on interfaces: there seems to be some
>> difference
>>>>> of opinion here. I'm not sure of the best approach to revolve this.
>> At the
>>>>> moment the KIP has factory methods on the new `Admin` interface,
>> rather
>>>>> than some utility class. I prefer the utility class, but this isn't
>> inline
>>>>> with the patterns in the code base and some of the core team have
>> expressed
>>>>> they'd prefer to continue to have the factory methods on the
>> interface.
>>>>> I'm happy with this if others are.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Andy
>>>>>
>>>>> On Thu, 27 Jun 2019 at 23:21, Matthias J. Sax <ma...@confluent.io>
>> wrote:
>>>>>
>>>>>> @Andy:
>>>>>>
>>>>>> What about the factory methods of `AdminClient` class? Should they
>> be
>>>>>> deprecated?
>>>>>>
>>>>>> One nit about the KIP: can you maybe insert "code blocks" to
>> highlight
>>>>>> the API changes? Code blocks would simplify to read the KIP a lot.
>>>>>>
>>>>>>
>>>>>> -Matthias
>>>>>>
>>>>>> On 6/26/19 6:56 AM, Ryanne Dolan wrote:
>>>>>>> +1 (non-binding)
>>>>>>>
>>>>>>> Thanks.
>>>>>>> Ryanne
>>>>>>>
>>>>>>> On Tue, Jun 25, 2019 at 10:21 PM Satish Duggana <
>>>>>> satish.duggana@gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> +1 (non-binding)
>>>>>>>>
>>>>>>>> On Wed, Jun 26, 2019 at 8:37 AM Satish Duggana <
>>>>>> satish.duggana@gmail.com>
>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> +1 Matthias/Andy.
>>>>>>>>> IMHO, interface is about the contract, it should not have/expose
>> any
>>>>>>>>> implementation. I am fine with either way as it is more of taste
>> or
>>>>>>>>> preference.
>>>>>>>>>
>>>>>>>>> Agree with Ismael/Colin/Ryanne on not deprecating for good
>> reasons.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Mon, Jun 24, 2019 at 8:33 PM Andy Coates <an...@confluent.io>
>> wrote:
>>>>>>>>>>
>>>>>>>>>> I agree Matthias.
>>>>>>>>>>
>>>>>>>>>> (In Scala, such factory methods are on a companion object. As
>> Java
>>>>>>>> doesn't
>>>>>>>>>> have the concept of a companion object, an equivalent would be a
>>>>>>>> utility
>>>>>>>>>> class with a similar name...)
>>>>>>>>>>
>>>>>>>>>> However, I'll update the KIP to include the factory method on
>> the
>>>>>>>> interface.
>>>>>>>>>>
>>>>>>>>>> On Fri, 21 Jun 2019 at 23:40, Matthias J. Sax <
>> matthias@confluent.io>
>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> I still think, that an interface does not need to know
>> anything about
>>>>>>>>>>> its implementation. But I am also fine if we add a factory
>> method to
>>>>>>>> the
>>>>>>>>>>> new interface if that is preferred by most people.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> -Matthias
>>>>>>>>>>>
>>>>>>>>>>> On 6/21/19 7:10 AM, Ismael Juma wrote:
>>>>>>>>>>>> This is even more reason not to deprecate immediately, there
>> is
>>>>>>>> very
>>>>>>>>>>> little
>>>>>>>>>>>> maintenance cost for us. We should be mindful that many of our
>>>>>>>> users (eg
>>>>>>>>>>>> Spark, Flink, etc.) typically allow users to specify the kafka
>>>>>>>> clients
>>>>>>>>>>>> version and hence avoid using new classes/interfaces for some
>>>>>>>> time. They
>>>>>>>>>>>> would get a bunch of warnings they cannot do anything about
>> apart
>>>>>>>> from
>>>>>>>>>>>> suppressing.
>>>>>>>>>>>>
>>>>>>>>>>>> Ismael
>>>>>>>>>>>>
>>>>>>>>>>>> On Fri, Jun 21, 2019 at 4:00 AM Andy Coates <
>> andy@confluent.io>
>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Hi Ismael,
>>>>>>>>>>>>>
>>>>>>>>>>>>> I’m happy enough to not deprecate the existing `AdminClient`
>>>>>>>> class as
>>>>>>>>>>> part
>>>>>>>>>>>>> of this change.
>>>>>>>>>>>>>
>>>>>>>>>>>>> However, note that, the class will likely be empty, i.e. all
>>>>>>>> methods and
>>>>>>>>>>>>> implementations will be inherited from the interface:
>>>>>>>>>>>>>
>>>>>>>>>>>>> public abstract class AdminClient implements Admin {
>>>>>>>>>>>>> }
>>>>>>>>>>>>>
>>>>>>>>>>>>> Not marking it as deprecated has the benefit that users
>> won’t see
>>>>>>>> any
>>>>>>>>>>>>> deprecation warnings on the next release. Conversely,
>> deprecating
>>>>>>>> it
>>>>>>>>>>> will
>>>>>>>>>>>>> mean we can choose to remove this, now pointless class, in
>> the
>>>>>>>> future
>>>>>>>>>>> if we
>>>>>>>>>>>>> choose.
>>>>>>>>>>>>>
>>>>>>>>>>>>> That’s my thinking for deprecation, but as I’ve said I’m
>> happy
>>>>>>>> either
>>>>>>>>>>> way.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Andy
>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 18 Jun 2019, at 16:09, Ismael Juma <is...@juma.me.uk>
>> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I agree with Ryanne, I think we should avoid deprecating
>>>>>>>> AdminClient
>>>>>>>>>>> and
>>>>>>>>>>>>>> causing so much churn for users who don't actually care
>> about
>>>>>>>> this
>>>>>>>>>>> niche
>>>>>>>>>>>>>> use case.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Ismael
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Tue, Jun 18, 2019 at 6:43 AM Andy Coates <
>> andy@confluent.io>
>>>>>>>> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Hi Ryanne,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> If we don't change the client code, then everywhere will
>> still
>>>>>>>> expect
>>>>>>>>>>>>>>> subclasses of `AdminClient`, so the interface will be of no
>>>>>>>> use, i.e.
>>>>>>>>>>> I
>>>>>>>>>>>>>>> can't write a class that implements the new interface and
>> pass
>>>>>>>> it to
>>>>>>>>>>> the
>>>>>>>>>>>>>>> client code.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Andy
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Mon, 17 Jun 2019 at 19:01, Ryanne Dolan <
>>>>>>>> ryannedolan@gmail.com>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Andy, while I agree that the new interface is useful, I'm
>> not
>>>>>>>>>>> convinced
>>>>>>>>>>>>>>>> adding an interface requires deprecating AdminClient and
>>>>>>>> changing so
>>>>>>>>>>>>> much
>>>>>>>>>>>>>>>> client code. Why not just add the Admin interface, have
>>>>>>>> AdminClient
>>>>>>>>>>>>>>>> implement it, and have done?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Ryanne
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On Mon, Jun 17, 2019 at 12:09 PM Andy Coates <
>>>>>>>> andy@confluent.io>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Hi all,
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I think I've addressed all concerns. Let me know if I've
>>>>>>>> not.  Can I
>>>>>>>>>>>>>>> call
>>>>>>>>>>>>>>>>> another round of votes please?
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Andy
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On Fri, 14 Jun 2019 at 04:55, Satish Duggana <
>>>>>>>>>>>>> satish.duggana@gmail.com
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Hi Andy,
>>>>>>>>>>>>>>>>>> Thanks for the KIP. This is a good change and it gives
>> the
>>>>>>>> user a
>>>>>>>>>>>>>>>> better
>>>>>>>>>>>>>>>>>> handle on Admin client usage. I agree with the proposal
>>>>>>>> except the
>>>>>>>>>>>>>>> new
>>>>>>>>>>>>>>>>>> `Admin` interface having all the methods from
>> `AdminClient`
>>>>>>>>>>> abstract
>>>>>>>>>>>>>>>>> class.
>>>>>>>>>>>>>>>>>> It should be kept clean having only the admin
>> operations as
>>>>>>>> methods
>>>>>>>>>>>>>>>> from
>>>>>>>>>>>>>>>>>> KafkaClient abstract class but not the factory methods
>> as
>>>>>>>> mentioned
>>>>>>>>>>>>>>> in
>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>> earlier mail.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> I know about dynamic proxies(which were widely used in
>>>>>>>> RMI/EJB
>>>>>>>>>>>>>>> world).
>>>>>>>>>>>>>>>> I
>>>>>>>>>>>>>>>>> am
>>>>>>>>>>>>>>>>>> curious about the usecase using dynamic proxies with
>> Admin
>>>>>>>> client
>>>>>>>>>>>>>>>>>> interface. Dynamic proxy can have performance penalty
>> if it
>>>>>>>> is used
>>>>>>>>>>>>>>> in
>>>>>>>>>>>>>>>>>> critical path. Is that the primary motivation for
>> creating
>>>>>>>> the KIP?
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>>> Satish.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On Wed, Jun 12, 2019 at 8:43 PM Andy Coates <
>>>>>>>> andy@confluent.io>
>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> I'm not married to that part.  That was only done to
>> keep
>>>>>>>> it more
>>>>>>>>>>>>>>> or
>>>>>>>>>>>>>>>>> less
>>>>>>>>>>>>>>>>>>> inline with what's already there, (an abstract class
>> that
>>>>>>>> has a
>>>>>>>>>>>>>>>> factory
>>>>>>>>>>>>>>>>>>> method that returns a subclass.... sounds like the same
>>>>>>>>>>>>>>> anti-pattern
>>>>>>>>>>>>>>>>> ;))
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> An alternative would to have an `AdminClients` utility
>>>>>>>> class to
>>>>>>>>>>>>>>>> create
>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>> admin client.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On Mon, 10 Jun 2019 at 19:31, Matthias J. Sax <
>>>>>>>>>>>>>>> matthias@confluent.io
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Hmmm...
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> So the new interface, returns an instance of a class
>> that
>>>>>>>>>>>>>>>> implements
>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>> interface. This sounds a little bit like an
>> anti-pattern?
>>>>>>>>>>>>>>> Shouldn't
>>>>>>>>>>>>>>>>>>>> interfaces actually not know anything about classes
>> that
>>>>>>>>>>>>>>> implement
>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>> interface?
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> -Matthias
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> On 6/10/19 11:22 AM, Andy Coates wrote:
>>>>>>>>>>>>>>>>>>>>> `AdminClient` would be deprecated purely because it
>> would
>>>>>>>> no
>>>>>>>>>>>>>>>> longer
>>>>>>>>>>>>>>>>>>> serve
>>>>>>>>>>>>>>>>>>>>> any purpose and would be virtually empty, getting
>> all of
>>>>>>>> its
>>>>>>>>>>>>>>>>>>>> implementation
>>>>>>>>>>>>>>>>>>>>> from the new interfar. It would be nice to remove
>> this
>>>>>>>> from the
>>>>>>>>>>>>>>>> API
>>>>>>>>>>>>>>>>>> at
>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>> next major version bump, hence the need to deprecate.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> `AdminClient.create()` would return what it does
>> today,
>>>>>>>> (so
>>>>>>>>>>>>>>> not a
>>>>>>>>>>>>>>>>>>>> breaking
>>>>>>>>>>>>>>>>>>>>> change).
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> On Tue, 4 Jun 2019 at 22:24, Ryanne Dolan <
>>>>>>>>>>>>>>> ryannedolan@gmail.com
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> The existing `AdminClient` will be marked as
>> deprecated.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> What's the reasoning behind this? I'm fine with the
>> other
>>>>>>>>>>>>>>>> changes,
>>>>>>>>>>>>>>>>>> but
>>>>>>>>>>>>>>>>>>>>>> would prefer to keep the existing public API intact
>> if
>>>>>>>> it's
>>>>>>>>>>>>>>> not
>>>>>>>>>>>>>>>>>>> hurting
>>>>>>>>>>>>>>>>>>>>>> anything.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Also, what will AdminClient.create() return? Would
>> it be
>>>>>>>> a
>>>>>>>>>>>>>>>>> breaking
>>>>>>>>>>>>>>>>>>>> change?
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Ryanne
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> On Tue, Jun 4, 2019, 11:17 AM Andy Coates <
>>>>>>>> andy@confluent.io>
>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Hi folks
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> As there's been no chatter on this KIP I'm
>> assuming it's
>>>>>>>>>>>>>>>>>>>> non-contentious,
>>>>>>>>>>>>>>>>>>>>>>> (or just boring), hence I'd like to call a vote for
>>>>>>>> KIP-476:
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>
>>>>>>
>> https://cwiki.apache.org/confluence/display/KAFKA/KIP-476%3A+Add+Java+AdminClient+Interface
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Andy
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>> Attachments:
>>>> * signature.asc
>>>
>>
>

Re: [VOTE] KIP-476: Add Java AdminClient interface

Posted by Andy Coates <an...@confluent.io>.

Matthias,

I was referring to platforms such as spark or flink that support multiple
versions of the Kafka clients. Ismael mentioned this higher up on the
thread.

I'd prefer this KIP didn't get held up over somewhat unrelated change, i.e.
should the factory method be on the interface or utility class.  Surely,
now would be a great time to change this if we wanted, but we can also
change this later if we need to.  In the interest of moving forward, can I
propose we leave the factory methods as they are in the KIP?

Thanks,

Andy

On Tue, 2 Jul 2019 at 17:14, Colin McCabe <cm...@apache.org> wrote:

> On Tue, Jul 2, 2019, at 09:14, Colin McCabe wrote:
> > On Mon, Jul 1, 2019, at 23:30, Matthias J. Sax wrote:
> > > Not sure, if I understand the argument?
> > >
> > > Why would anyone need to support multiple client side versions?
> > > Clients/brokers are forward/backward compatible anyway.
> >
> > When you're using many different libraries, it is helpful if they don't
> > impose tight constraints on what versions their dependencies are.
> > Otherwise you can easily get in a situation where the constraints can't
> > be satisfied.
> >
> > >
> > > Also, if one really supports multiple client side versions, won't they
> > > use multiple shaded dependencies for different versions?
> >
> > Shading the Kafka client doesn't really work, because of how we use
> reflection.
> >
> > >
> > > Last, it's possible to suppress warnings (at least in Java).
> >
> > But not in Scala.  So that does not help (for example), Scala users.
>
> I meant to write "Spark users" here.
>
> C.
>
> >
> > I agree that in general we should be using deprecation when
> > appropriate, regardless of the potential annoyances to users.  But I'm
> > not sure deprecating this method is really worth it.
> >
> > best,
> > Colin
> >
> >
> > >
> > > Can you elaborate?
> > >
> > > IMHO, just adding a statement to JavaDocs is a little weak, and at some
> > > point, we need to deprecate those methods anyway if we ever want to
> > > remove them. The earlier we deprecate them, the earlier we can remove
> them.
> > >
> > >
> > > -Matthias
> > >
> > > On 7/1/19 4:22 AM, Andy Coates wrote:
> > > > Done. I've not deprecated the factory methods on the AdminClient for
> the
> > > > same reason the AdminClient itself is not deprecated, i.e. this
> would cause
> > > > unavoidable warnings for libraries / platforms that support multiple
> > > > versions of Kafka. However, I think we add a note to the Java docs of
> > > > `AdminClient` to indicate that its use, going forward, is
> discouraged in
> > > > favour of the new `Admin` interface and explain why its not  been
> > > > deprecated, but that it may/will be removed in a future version.
> > > >
> > > > Regarding factory methods on interfaces: there seems to be some
> difference
> > > > of opinion here. I'm not sure of the best approach to revolve this.
> At the
> > > > moment the KIP has factory methods on the new `Admin` interface,
> rather
> > > > than some utility class. I prefer the utility class, but this isn't
> inline
> > > > with the patterns in the code base and some of the core team have
> expressed
> > > > they'd prefer to continue to have the factory methods on the
> interface.
> > > > I'm happy with this if others are.
> > > >
> > > > Thanks,
> > > >
> > > > Andy
> > > >
> > > > On Thu, 27 Jun 2019 at 23:21, Matthias J. Sax <ma...@confluent.io>
> wrote:
> > > >
> > > >> @Andy:
> > > >>
> > > >> What about the factory methods of `AdminClient` class? Should they
> be
> > > >> deprecated?
> > > >>
> > > >> One nit about the KIP: can you maybe insert "code blocks" to
> highlight
> > > >> the API changes? Code blocks would simplify to read the KIP a lot.
> > > >>
> > > >>
> > > >> -Matthias
> > > >>
> > > >> On 6/26/19 6:56 AM, Ryanne Dolan wrote:
> > > >>> +1 (non-binding)
> > > >>>
> > > >>> Thanks.
> > > >>> Ryanne
> > > >>>
> > > >>> On Tue, Jun 25, 2019 at 10:21 PM Satish Duggana <
> > > >> satish.duggana@gmail.com>
> > > >>> wrote:
> > > >>>
> > > >>>> +1 (non-binding)
> > > >>>>
> > > >>>> On Wed, Jun 26, 2019 at 8:37 AM Satish Duggana <
> > > >> satish.duggana@gmail.com>
> > > >>>> wrote:
> > > >>>>>
> > > >>>>> +1 Matthias/Andy.
> > > >>>>> IMHO, interface is about the contract, it should not have/expose
> any
> > > >>>>> implementation. I am fine with either way as it is more of taste
> or
> > > >>>>> preference.
> > > >>>>>
> > > >>>>> Agree with Ismael/Colin/Ryanne on not deprecating for good
> reasons.
> > > >>>>>
> > > >>>>>
> > > >>>>> On Mon, Jun 24, 2019 at 8:33 PM Andy Coates <an...@confluent.io>
> wrote:
> > > >>>>>>
> > > >>>>>> I agree Matthias.
> > > >>>>>>
> > > >>>>>> (In Scala, such factory methods are on a companion object. As
> Java
> > > >>>> doesn't
> > > >>>>>> have the concept of a companion object, an equivalent would be a
> > > >>>> utility
> > > >>>>>> class with a similar name...)
> > > >>>>>>
> > > >>>>>> However, I'll update the KIP to include the factory method on
> the
> > > >>>> interface.
> > > >>>>>>
> > > >>>>>> On Fri, 21 Jun 2019 at 23:40, Matthias J. Sax <
> matthias@confluent.io>
> > > >>>> wrote:
> > > >>>>>>
> > > >>>>>>> I still think, that an interface does not need to know
> anything about
> > > >>>>>>> its implementation. But I am also fine if we add a factory
> method to
> > > >>>> the
> > > >>>>>>> new interface if that is preferred by most people.
> > > >>>>>>>
> > > >>>>>>>
> > > >>>>>>> -Matthias
> > > >>>>>>>
> > > >>>>>>> On 6/21/19 7:10 AM, Ismael Juma wrote:
> > > >>>>>>>> This is even more reason not to deprecate immediately, there
> is
> > > >>>> very
> > > >>>>>>> little
> > > >>>>>>>> maintenance cost for us. We should be mindful that many of our
> > > >>>> users (eg
> > > >>>>>>>> Spark, Flink, etc.) typically allow users to specify the kafka
> > > >>>> clients
> > > >>>>>>>> version and hence avoid using new classes/interfaces for some
> > > >>>> time. They
> > > >>>>>>>> would get a bunch of warnings they cannot do anything about
> apart
> > > >>>> from
> > > >>>>>>>> suppressing.
> > > >>>>>>>>
> > > >>>>>>>> Ismael
> > > >>>>>>>>
> > > >>>>>>>> On Fri, Jun 21, 2019 at 4:00 AM Andy Coates <
> andy@confluent.io>
> > > >>>> wrote:
> > > >>>>>>>>
> > > >>>>>>>>> Hi Ismael,
> > > >>>>>>>>>
> > > >>>>>>>>> I’m happy enough to not deprecate the existing `AdminClient`
> > > >>>> class as
> > > >>>>>>> part
> > > >>>>>>>>> of this change.
> > > >>>>>>>>>
> > > >>>>>>>>> However, note that, the class will likely be empty, i.e. all
> > > >>>> methods and
> > > >>>>>>>>> implementations will be inherited from the interface:
> > > >>>>>>>>>
> > > >>>>>>>>> public abstract class AdminClient implements Admin {
> > > >>>>>>>>> }
> > > >>>>>>>>>
> > > >>>>>>>>> Not marking it as deprecated has the benefit that users
> won’t see
> > > >>>> any
> > > >>>>>>>>> deprecation warnings on the next release. Conversely,
> deprecating
> > > >>>> it
> > > >>>>>>> will
> > > >>>>>>>>> mean we can choose to remove this, now pointless class, in
> the
> > > >>>> future
> > > >>>>>>> if we
> > > >>>>>>>>> choose.
> > > >>>>>>>>>
> > > >>>>>>>>> That’s my thinking for deprecation, but as I’ve said I’m
> happy
> > > >>>> either
> > > >>>>>>> way.
> > > >>>>>>>>>
> > > >>>>>>>>> Andy
> > > >>>>>>>>>
> > > >>>>>>>>>> On 18 Jun 2019, at 16:09, Ismael Juma <is...@juma.me.uk>
> wrote:
> > > >>>>>>>>>>
> > > >>>>>>>>>> I agree with Ryanne, I think we should avoid deprecating
> > > >>>> AdminClient
> > > >>>>>>> and
> > > >>>>>>>>>> causing so much churn for users who don't actually care
> about
> > > >>>> this
> > > >>>>>>> niche
> > > >>>>>>>>>> use case.
> > > >>>>>>>>>>
> > > >>>>>>>>>> Ismael
> > > >>>>>>>>>>
> > > >>>>>>>>>> On Tue, Jun 18, 2019 at 6:43 AM Andy Coates <
> andy@confluent.io>
> > > >>>> wrote:
> > > >>>>>>>>>>
> > > >>>>>>>>>>> Hi Ryanne,
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> If we don't change the client code, then everywhere will
> still
> > > >>>> expect
> > > >>>>>>>>>>> subclasses of `AdminClient`, so the interface will be of no
> > > >>>> use, i.e.
> > > >>>>>>> I
> > > >>>>>>>>>>> can't write a class that implements the new interface and
> pass
> > > >>>> it to
> > > >>>>>>> the
> > > >>>>>>>>>>> client code.
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> Thanks,
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> Andy
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> On Mon, 17 Jun 2019 at 19:01, Ryanne Dolan <
> > > >>>> ryannedolan@gmail.com>
> > > >>>>>>>>> wrote:
> > > >>>>>>>>>>>
> > > >>>>>>>>>>>> Andy, while I agree that the new interface is useful, I'm
> not
> > > >>>>>>> convinced
> > > >>>>>>>>>>>> adding an interface requires deprecating AdminClient and
> > > >>>> changing so
> > > >>>>>>>>> much
> > > >>>>>>>>>>>> client code. Why not just add the Admin interface, have
> > > >>>> AdminClient
> > > >>>>>>>>>>>> implement it, and have done?
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> Ryanne
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> On Mon, Jun 17, 2019 at 12:09 PM Andy Coates <
> > > >>>> andy@confluent.io>
> > > >>>>>>>>> wrote:
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>>> Hi all,
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>> I think I've addressed all concerns. Let me know if I've
> > > >>>> not.  Can I
> > > >>>>>>>>>>> call
> > > >>>>>>>>>>>>> another round of votes please?
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>> Thanks,
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>> Andy
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>> On Fri, 14 Jun 2019 at 04:55, Satish Duggana <
> > > >>>>>>>>> satish.duggana@gmail.com
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>>> wrote:
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>>> Hi Andy,
> > > >>>>>>>>>>>>>> Thanks for the KIP. This is a good change and it gives
> the
> > > >>>> user a
> > > >>>>>>>>>>>> better
> > > >>>>>>>>>>>>>> handle on Admin client usage. I agree with the proposal
> > > >>>> except the
> > > >>>>>>>>>>> new
> > > >>>>>>>>>>>>>> `Admin` interface having all the methods from
> `AdminClient`
> > > >>>>>>> abstract
> > > >>>>>>>>>>>>> class.
> > > >>>>>>>>>>>>>> It should be kept clean having only the admin
> operations as
> > > >>>> methods
> > > >>>>>>>>>>>> from
> > > >>>>>>>>>>>>>> KafkaClient abstract class but not the factory methods
> as
> > > >>>> mentioned
> > > >>>>>>>>>>> in
> > > >>>>>>>>>>>>> the
> > > >>>>>>>>>>>>>> earlier mail.
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>> I know about dynamic proxies(which were widely used in
> > > >>>> RMI/EJB
> > > >>>>>>>>>>> world).
> > > >>>>>>>>>>>> I
> > > >>>>>>>>>>>>> am
> > > >>>>>>>>>>>>>> curious about the usecase using dynamic proxies with
> Admin
> > > >>>> client
> > > >>>>>>>>>>>>>> interface. Dynamic proxy can have performance penalty
> if it
> > > >>>> is used
> > > >>>>>>>>>>> in
> > > >>>>>>>>>>>>>> critical path. Is that the primary motivation for
> creating
> > > >>>> the KIP?
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>> Thanks,
> > > >>>>>>>>>>>>>> Satish.
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>> On Wed, Jun 12, 2019 at 8:43 PM Andy Coates <
> > > >>>> andy@confluent.io>
> > > >>>>>>>>>>> wrote:
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>> I'm not married to that part.  That was only done to
> keep
> > > >>>> it more
> > > >>>>>>>>>>> or
> > > >>>>>>>>>>>>> less
> > > >>>>>>>>>>>>>>> inline with what's already there, (an abstract class
> that
> > > >>>> has a
> > > >>>>>>>>>>>> factory
> > > >>>>>>>>>>>>>>> method that returns a subclass.... sounds like the same
> > > >>>>>>>>>>> anti-pattern
> > > >>>>>>>>>>>>> ;))
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>> An alternative would to have an `AdminClients` utility
> > > >>>> class to
> > > >>>>>>>>>>>> create
> > > >>>>>>>>>>>>>> the
> > > >>>>>>>>>>>>>>> admin client.
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>> On Mon, 10 Jun 2019 at 19:31, Matthias J. Sax <
> > > >>>>>>>>>>> matthias@confluent.io
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>> wrote:
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> Hmmm...
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> So the new interface, returns an instance of a class
> that
> > > >>>>>>>>>>>> implements
> > > >>>>>>>>>>>>>> the
> > > >>>>>>>>>>>>>>>> interface. This sounds a little bit like an
> anti-pattern?
> > > >>>>>>>>>>> Shouldn't
> > > >>>>>>>>>>>>>>>> interfaces actually not know anything about classes
> that
> > > >>>>>>>>>>> implement
> > > >>>>>>>>>>>>> the
> > > >>>>>>>>>>>>>>>> interface?
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> -Matthias
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> On 6/10/19 11:22 AM, Andy Coates wrote:
> > > >>>>>>>>>>>>>>>>> `AdminClient` would be deprecated purely because it
> would
> > > >>>> no
> > > >>>>>>>>>>>> longer
> > > >>>>>>>>>>>>>>> serve
> > > >>>>>>>>>>>>>>>>> any purpose and would be virtually empty, getting
> all of
> > > >>>> its
> > > >>>>>>>>>>>>>>>> implementation
> > > >>>>>>>>>>>>>>>>> from the new interfar. It would be nice to remove
> this
> > > >>>> from the
> > > >>>>>>>>>>>> API
> > > >>>>>>>>>>>>>> at
> > > >>>>>>>>>>>>>>>> the
> > > >>>>>>>>>>>>>>>>> next major version bump, hence the need to deprecate.
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> `AdminClient.create()` would return what it does
> today,
> > > >>>> (so
> > > >>>>>>>>>>> not a
> > > >>>>>>>>>>>>>>>> breaking
> > > >>>>>>>>>>>>>>>>> change).
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> On Tue, 4 Jun 2019 at 22:24, Ryanne Dolan <
> > > >>>>>>>>>>> ryannedolan@gmail.com
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>> wrote:
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>> The existing `AdminClient` will be marked as
> deprecated.
> > > >>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>> What's the reasoning behind this? I'm fine with the
> other
> > > >>>>>>>>>>>> changes,
> > > >>>>>>>>>>>>>> but
> > > >>>>>>>>>>>>>>>>>> would prefer to keep the existing public API intact
> if
> > > >>>> it's
> > > >>>>>>>>>>> not
> > > >>>>>>>>>>>>>>> hurting
> > > >>>>>>>>>>>>>>>>>> anything.
> > > >>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>> Also, what will AdminClient.create() return? Would
> it be
> > > >>>> a
> > > >>>>>>>>>>>>> breaking
> > > >>>>>>>>>>>>>>>> change?
> > > >>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>> Ryanne
> > > >>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>> On Tue, Jun 4, 2019, 11:17 AM Andy Coates <
> > > >>>> andy@confluent.io>
> > > >>>>>>>>>>>>>> wrote:
> > > >>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>> Hi folks
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>> As there's been no chatter on this KIP I'm
> assuming it's
> > > >>>>>>>>>>>>>>>> non-contentious,
> > > >>>>>>>>>>>>>>>>>>> (or just boring), hence I'd like to call a vote for
> > > >>>> KIP-476:
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>
> > > >>>>>>>>>
> > > >>>>>>>
> > > >>>>
> > > >>
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-476%3A+Add+Java+AdminClient+Interface
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>> Thanks,
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>> Andy
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>
> > > >>>>>>>>>
> > > >>>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>
> > > >>>>>>>
> > > >>>>
> > > >>>
> > > >>
> > > >>
> > > >
> > >
> > >
> > > Attachments:
> > > * signature.asc
> >
>

Re: [VOTE] KIP-476: Add Java AdminClient interface

Posted by Colin McCabe <cm...@apache.org>.

On Tue, Jul 2, 2019, at 09:14, Colin McCabe wrote:
> On Mon, Jul 1, 2019, at 23:30, Matthias J. Sax wrote:
> > Not sure, if I understand the argument?
> > 
> > Why would anyone need to support multiple client side versions?
> > Clients/brokers are forward/backward compatible anyway.
> 
> When you're using many different libraries, it is helpful if they don't 
> impose tight constraints on what versions their dependencies are.  
> Otherwise you can easily get in a situation where the constraints can't 
> be satisfied.
> 
> > 
> > Also, if one really supports multiple client side versions, won't they
> > use multiple shaded dependencies for different versions?
> 
> Shading the Kafka client doesn't really work, because of how we use reflection.
> 
> > 
> > Last, it's possible to suppress warnings (at least in Java).
> 
> But not in Scala.  So that does not help (for example), Scala users.

I meant to write "Spark users" here.

C.

> 
> I agree that in general we should be using deprecation when 
> appropriate, regardless of the potential annoyances to users.  But I'm 
> not sure deprecating this method is really worth it.
> 
> best,
> Colin
> 
> 
> > 
> > Can you elaborate?
> > 
> > IMHO, just adding a statement to JavaDocs is a little weak, and at some
> > point, we need to deprecate those methods anyway if we ever want to
> > remove them. The earlier we deprecate them, the earlier we can remove them.
> > 
> > 
> > -Matthias
> > 
> > On 7/1/19 4:22 AM, Andy Coates wrote:
> > > Done. I've not deprecated the factory methods on the AdminClient for the
> > > same reason the AdminClient itself is not deprecated, i.e. this would cause
> > > unavoidable warnings for libraries / platforms that support multiple
> > > versions of Kafka. However, I think we add a note to the Java docs of
> > > `AdminClient` to indicate that its use, going forward, is discouraged in
> > > favour of the new `Admin` interface and explain why its not  been
> > > deprecated, but that it may/will be removed in a future version.
> > > 
> > > Regarding factory methods on interfaces: there seems to be some difference
> > > of opinion here. I'm not sure of the best approach to revolve this. At the
> > > moment the KIP has factory methods on the new `Admin` interface, rather
> > > than some utility class. I prefer the utility class, but this isn't inline
> > > with the patterns in the code base and some of the core team have expressed
> > > they'd prefer to continue to have the factory methods on the interface.
> > > I'm happy with this if others are.
> > > 
> > > Thanks,
> > > 
> > > Andy
> > > 
> > > On Thu, 27 Jun 2019 at 23:21, Matthias J. Sax <ma...@confluent.io> wrote:
> > > 
> > >> @Andy:
> > >>
> > >> What about the factory methods of `AdminClient` class? Should they be
> > >> deprecated?
> > >>
> > >> One nit about the KIP: can you maybe insert "code blocks" to highlight
> > >> the API changes? Code blocks would simplify to read the KIP a lot.
> > >>
> > >>
> > >> -Matthias
> > >>
> > >> On 6/26/19 6:56 AM, Ryanne Dolan wrote:
> > >>> +1 (non-binding)
> > >>>
> > >>> Thanks.
> > >>> Ryanne
> > >>>
> > >>> On Tue, Jun 25, 2019 at 10:21 PM Satish Duggana <
> > >> satish.duggana@gmail.com>
> > >>> wrote:
> > >>>
> > >>>> +1 (non-binding)
> > >>>>
> > >>>> On Wed, Jun 26, 2019 at 8:37 AM Satish Duggana <
> > >> satish.duggana@gmail.com>
> > >>>> wrote:
> > >>>>>
> > >>>>> +1 Matthias/Andy.
> > >>>>> IMHO, interface is about the contract, it should not have/expose any
> > >>>>> implementation. I am fine with either way as it is more of taste or
> > >>>>> preference.
> > >>>>>
> > >>>>> Agree with Ismael/Colin/Ryanne on not deprecating for good reasons.
> > >>>>>
> > >>>>>
> > >>>>> On Mon, Jun 24, 2019 at 8:33 PM Andy Coates <an...@confluent.io> wrote:
> > >>>>>>
> > >>>>>> I agree Matthias.
> > >>>>>>
> > >>>>>> (In Scala, such factory methods are on a companion object. As Java
> > >>>> doesn't
> > >>>>>> have the concept of a companion object, an equivalent would be a
> > >>>> utility
> > >>>>>> class with a similar name...)
> > >>>>>>
> > >>>>>> However, I'll update the KIP to include the factory method on the
> > >>>> interface.
> > >>>>>>
> > >>>>>> On Fri, 21 Jun 2019 at 23:40, Matthias J. Sax <ma...@confluent.io>
> > >>>> wrote:
> > >>>>>>
> > >>>>>>> I still think, that an interface does not need to know anything about
> > >>>>>>> its implementation. But I am also fine if we add a factory method to
> > >>>> the
> > >>>>>>> new interface if that is preferred by most people.
> > >>>>>>>
> > >>>>>>>
> > >>>>>>> -Matthias
> > >>>>>>>
> > >>>>>>> On 6/21/19 7:10 AM, Ismael Juma wrote:
> > >>>>>>>> This is even more reason not to deprecate immediately, there is
> > >>>> very
> > >>>>>>> little
> > >>>>>>>> maintenance cost for us. We should be mindful that many of our
> > >>>> users (eg
> > >>>>>>>> Spark, Flink, etc.) typically allow users to specify the kafka
> > >>>> clients
> > >>>>>>>> version and hence avoid using new classes/interfaces for some
> > >>>> time. They
> > >>>>>>>> would get a bunch of warnings they cannot do anything about apart
> > >>>> from
> > >>>>>>>> suppressing.
> > >>>>>>>>
> > >>>>>>>> Ismael
> > >>>>>>>>
> > >>>>>>>> On Fri, Jun 21, 2019 at 4:00 AM Andy Coates <an...@confluent.io>
> > >>>> wrote:
> > >>>>>>>>
> > >>>>>>>>> Hi Ismael,
> > >>>>>>>>>
> > >>>>>>>>> I’m happy enough to not deprecate the existing `AdminClient`
> > >>>> class as
> > >>>>>>> part
> > >>>>>>>>> of this change.
> > >>>>>>>>>
> > >>>>>>>>> However, note that, the class will likely be empty, i.e. all
> > >>>> methods and
> > >>>>>>>>> implementations will be inherited from the interface:
> > >>>>>>>>>
> > >>>>>>>>> public abstract class AdminClient implements Admin {
> > >>>>>>>>> }
> > >>>>>>>>>
> > >>>>>>>>> Not marking it as deprecated has the benefit that users won’t see
> > >>>> any
> > >>>>>>>>> deprecation warnings on the next release. Conversely, deprecating
> > >>>> it
> > >>>>>>> will
> > >>>>>>>>> mean we can choose to remove this, now pointless class, in the
> > >>>> future
> > >>>>>>> if we
> > >>>>>>>>> choose.
> > >>>>>>>>>
> > >>>>>>>>> That’s my thinking for deprecation, but as I’ve said I’m happy
> > >>>> either
> > >>>>>>> way.
> > >>>>>>>>>
> > >>>>>>>>> Andy
> > >>>>>>>>>
> > >>>>>>>>>> On 18 Jun 2019, at 16:09, Ismael Juma <is...@juma.me.uk> wrote:
> > >>>>>>>>>>
> > >>>>>>>>>> I agree with Ryanne, I think we should avoid deprecating
> > >>>> AdminClient
> > >>>>>>> and
> > >>>>>>>>>> causing so much churn for users who don't actually care about
> > >>>> this
> > >>>>>>> niche
> > >>>>>>>>>> use case.
> > >>>>>>>>>>
> > >>>>>>>>>> Ismael
> > >>>>>>>>>>
> > >>>>>>>>>> On Tue, Jun 18, 2019 at 6:43 AM Andy Coates <an...@confluent.io>
> > >>>> wrote:
> > >>>>>>>>>>
> > >>>>>>>>>>> Hi Ryanne,
> > >>>>>>>>>>>
> > >>>>>>>>>>> If we don't change the client code, then everywhere will still
> > >>>> expect
> > >>>>>>>>>>> subclasses of `AdminClient`, so the interface will be of no
> > >>>> use, i.e.
> > >>>>>>> I
> > >>>>>>>>>>> can't write a class that implements the new interface and pass
> > >>>> it to
> > >>>>>>> the
> > >>>>>>>>>>> client code.
> > >>>>>>>>>>>
> > >>>>>>>>>>> Thanks,
> > >>>>>>>>>>>
> > >>>>>>>>>>> Andy
> > >>>>>>>>>>>
> > >>>>>>>>>>> On Mon, 17 Jun 2019 at 19:01, Ryanne Dolan <
> > >>>> ryannedolan@gmail.com>
> > >>>>>>>>> wrote:
> > >>>>>>>>>>>
> > >>>>>>>>>>>> Andy, while I agree that the new interface is useful, I'm not
> > >>>>>>> convinced
> > >>>>>>>>>>>> adding an interface requires deprecating AdminClient and
> > >>>> changing so
> > >>>>>>>>> much
> > >>>>>>>>>>>> client code. Why not just add the Admin interface, have
> > >>>> AdminClient
> > >>>>>>>>>>>> implement it, and have done?
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> Ryanne
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> On Mon, Jun 17, 2019 at 12:09 PM Andy Coates <
> > >>>> andy@confluent.io>
> > >>>>>>>>> wrote:
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>> Hi all,
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> I think I've addressed all concerns. Let me know if I've
> > >>>> not.  Can I
> > >>>>>>>>>>> call
> > >>>>>>>>>>>>> another round of votes please?
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> Thanks,
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> Andy
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> On Fri, 14 Jun 2019 at 04:55, Satish Duggana <
> > >>>>>>>>> satish.duggana@gmail.com
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>> wrote:
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>> Hi Andy,
> > >>>>>>>>>>>>>> Thanks for the KIP. This is a good change and it gives the
> > >>>> user a
> > >>>>>>>>>>>> better
> > >>>>>>>>>>>>>> handle on Admin client usage. I agree with the proposal
> > >>>> except the
> > >>>>>>>>>>> new
> > >>>>>>>>>>>>>> `Admin` interface having all the methods from `AdminClient`
> > >>>>>>> abstract
> > >>>>>>>>>>>>> class.
> > >>>>>>>>>>>>>> It should be kept clean having only the admin operations as
> > >>>> methods
> > >>>>>>>>>>>> from
> > >>>>>>>>>>>>>> KafkaClient abstract class but not the factory methods as
> > >>>> mentioned
> > >>>>>>>>>>> in
> > >>>>>>>>>>>>> the
> > >>>>>>>>>>>>>> earlier mail.
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>> I know about dynamic proxies(which were widely used in
> > >>>> RMI/EJB
> > >>>>>>>>>>> world).
> > >>>>>>>>>>>> I
> > >>>>>>>>>>>>> am
> > >>>>>>>>>>>>>> curious about the usecase using dynamic proxies with Admin
> > >>>> client
> > >>>>>>>>>>>>>> interface. Dynamic proxy can have performance penalty if it
> > >>>> is used
> > >>>>>>>>>>> in
> > >>>>>>>>>>>>>> critical path. Is that the primary motivation for creating
> > >>>> the KIP?
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>> Thanks,
> > >>>>>>>>>>>>>> Satish.
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>> On Wed, Jun 12, 2019 at 8:43 PM Andy Coates <
> > >>>> andy@confluent.io>
> > >>>>>>>>>>> wrote:
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> I'm not married to that part.  That was only done to keep
> > >>>> it more
> > >>>>>>>>>>> or
> > >>>>>>>>>>>>> less
> > >>>>>>>>>>>>>>> inline with what's already there, (an abstract class that
> > >>>> has a
> > >>>>>>>>>>>> factory
> > >>>>>>>>>>>>>>> method that returns a subclass.... sounds like the same
> > >>>>>>>>>>> anti-pattern
> > >>>>>>>>>>>>> ;))
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> An alternative would to have an `AdminClients` utility
> > >>>> class to
> > >>>>>>>>>>>> create
> > >>>>>>>>>>>>>> the
> > >>>>>>>>>>>>>>> admin client.
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> On Mon, 10 Jun 2019 at 19:31, Matthias J. Sax <
> > >>>>>>>>>>> matthias@confluent.io
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> wrote:
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> Hmmm...
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> So the new interface, returns an instance of a class that
> > >>>>>>>>>>>> implements
> > >>>>>>>>>>>>>> the
> > >>>>>>>>>>>>>>>> interface. This sounds a little bit like an anti-pattern?
> > >>>>>>>>>>> Shouldn't
> > >>>>>>>>>>>>>>>> interfaces actually not know anything about classes that
> > >>>>>>>>>>> implement
> > >>>>>>>>>>>>> the
> > >>>>>>>>>>>>>>>> interface?
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> -Matthias
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> On 6/10/19 11:22 AM, Andy Coates wrote:
> > >>>>>>>>>>>>>>>>> `AdminClient` would be deprecated purely because it would
> > >>>> no
> > >>>>>>>>>>>> longer
> > >>>>>>>>>>>>>>> serve
> > >>>>>>>>>>>>>>>>> any purpose and would be virtually empty, getting all of
> > >>>> its
> > >>>>>>>>>>>>>>>> implementation
> > >>>>>>>>>>>>>>>>> from the new interfar. It would be nice to remove this
> > >>>> from the
> > >>>>>>>>>>>> API
> > >>>>>>>>>>>>>> at
> > >>>>>>>>>>>>>>>> the
> > >>>>>>>>>>>>>>>>> next major version bump, hence the need to deprecate.
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> `AdminClient.create()` would return what it does today,
> > >>>> (so
> > >>>>>>>>>>> not a
> > >>>>>>>>>>>>>>>> breaking
> > >>>>>>>>>>>>>>>>> change).
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> On Tue, 4 Jun 2019 at 22:24, Ryanne Dolan <
> > >>>>>>>>>>> ryannedolan@gmail.com
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> wrote:
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>> The existing `AdminClient` will be marked as deprecated.
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>> What's the reasoning behind this? I'm fine with the other
> > >>>>>>>>>>>> changes,
> > >>>>>>>>>>>>>> but
> > >>>>>>>>>>>>>>>>>> would prefer to keep the existing public API intact if
> > >>>> it's
> > >>>>>>>>>>> not
> > >>>>>>>>>>>>>>> hurting
> > >>>>>>>>>>>>>>>>>> anything.
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>> Also, what will AdminClient.create() return? Would it be
> > >>>> a
> > >>>>>>>>>>>>> breaking
> > >>>>>>>>>>>>>>>> change?
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>> Ryanne
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>> On Tue, Jun 4, 2019, 11:17 AM Andy Coates <
> > >>>> andy@confluent.io>
> > >>>>>>>>>>>>>> wrote:
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>> Hi folks
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>> As there's been no chatter on this KIP I'm assuming it's
> > >>>>>>>>>>>>>>>> non-contentious,
> > >>>>>>>>>>>>>>>>>>> (or just boring), hence I'd like to call a vote for
> > >>>> KIP-476:
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>
> > >>>>
> > >> https://cwiki.apache.org/confluence/display/KAFKA/KIP-476%3A+Add+Java+AdminClient+Interface
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>> Thanks,
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>> Andy
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>
> > >>>
> > >>
> > >>
> > > 
> > 
> > 
> > Attachments:
> > * signature.asc
>

Re: [VOTE] KIP-476: Add Java AdminClient interface

Posted by Colin McCabe <cm...@apache.org>.

On Mon, Jul 1, 2019, at 23:30, Matthias J. Sax wrote:
> Not sure, if I understand the argument?
> 
> Why would anyone need to support multiple client side versions?
> Clients/brokers are forward/backward compatible anyway.

When you're using many different libraries, it is helpful if they don't impose tight constraints on what versions their dependencies are.  Otherwise you can easily get in a situation where the constraints can't be satisfied.

> 
> Also, if one really supports multiple client side versions, won't they
> use multiple shaded dependencies for different versions?

Shading the Kafka client doesn't really work, because of how we use reflection.

> 
> Last, it's possible to suppress warnings (at least in Java).

But not in Scala.  So that does not help (for example), Scala users.

I agree that in general we should be using deprecation when appropriate, regardless of the potential annoyances to users.  But I'm not sure deprecating this method is really worth it.

best,
Colin


> 
> Can you elaborate?
> 
> IMHO, just adding a statement to JavaDocs is a little weak, and at some
> point, we need to deprecate those methods anyway if we ever want to
> remove them. The earlier we deprecate them, the earlier we can remove them.
> 
> 
> -Matthias
> 
> On 7/1/19 4:22 AM, Andy Coates wrote:
> > Done. I've not deprecated the factory methods on the AdminClient for the
> > same reason the AdminClient itself is not deprecated, i.e. this would cause
> > unavoidable warnings for libraries / platforms that support multiple
> > versions of Kafka. However, I think we add a note to the Java docs of
> > `AdminClient` to indicate that its use, going forward, is discouraged in
> > favour of the new `Admin` interface and explain why its not  been
> > deprecated, but that it may/will be removed in a future version.
> > 
> > Regarding factory methods on interfaces: there seems to be some difference
> > of opinion here. I'm not sure of the best approach to revolve this. At the
> > moment the KIP has factory methods on the new `Admin` interface, rather
> > than some utility class. I prefer the utility class, but this isn't inline
> > with the patterns in the code base and some of the core team have expressed
> > they'd prefer to continue to have the factory methods on the interface.
> > I'm happy with this if others are.
> > 
> > Thanks,
> > 
> > Andy
> > 
> > On Thu, 27 Jun 2019 at 23:21, Matthias J. Sax <ma...@confluent.io> wrote:
> > 
> >> @Andy:
> >>
> >> What about the factory methods of `AdminClient` class? Should they be
> >> deprecated?
> >>
> >> One nit about the KIP: can you maybe insert "code blocks" to highlight
> >> the API changes? Code blocks would simplify to read the KIP a lot.
> >>
> >>
> >> -Matthias
> >>
> >> On 6/26/19 6:56 AM, Ryanne Dolan wrote:
> >>> +1 (non-binding)
> >>>
> >>> Thanks.
> >>> Ryanne
> >>>
> >>> On Tue, Jun 25, 2019 at 10:21 PM Satish Duggana <
> >> satish.duggana@gmail.com>
> >>> wrote:
> >>>
> >>>> +1 (non-binding)
> >>>>
> >>>> On Wed, Jun 26, 2019 at 8:37 AM Satish Duggana <
> >> satish.duggana@gmail.com>
> >>>> wrote:
> >>>>>
> >>>>> +1 Matthias/Andy.
> >>>>> IMHO, interface is about the contract, it should not have/expose any
> >>>>> implementation. I am fine with either way as it is more of taste or
> >>>>> preference.
> >>>>>
> >>>>> Agree with Ismael/Colin/Ryanne on not deprecating for good reasons.
> >>>>>
> >>>>>
> >>>>> On Mon, Jun 24, 2019 at 8:33 PM Andy Coates <an...@confluent.io> wrote:
> >>>>>>
> >>>>>> I agree Matthias.
> >>>>>>
> >>>>>> (In Scala, such factory methods are on a companion object. As Java
> >>>> doesn't
> >>>>>> have the concept of a companion object, an equivalent would be a
> >>>> utility
> >>>>>> class with a similar name...)
> >>>>>>
> >>>>>> However, I'll update the KIP to include the factory method on the
> >>>> interface.
> >>>>>>
> >>>>>> On Fri, 21 Jun 2019 at 23:40, Matthias J. Sax <ma...@confluent.io>
> >>>> wrote:
> >>>>>>
> >>>>>>> I still think, that an interface does not need to know anything about
> >>>>>>> its implementation. But I am also fine if we add a factory method to
> >>>> the
> >>>>>>> new interface if that is preferred by most people.
> >>>>>>>
> >>>>>>>
> >>>>>>> -Matthias
> >>>>>>>
> >>>>>>> On 6/21/19 7:10 AM, Ismael Juma wrote:
> >>>>>>>> This is even more reason not to deprecate immediately, there is
> >>>> very
> >>>>>>> little
> >>>>>>>> maintenance cost for us. We should be mindful that many of our
> >>>> users (eg
> >>>>>>>> Spark, Flink, etc.) typically allow users to specify the kafka
> >>>> clients
> >>>>>>>> version and hence avoid using new classes/interfaces for some
> >>>> time. They
> >>>>>>>> would get a bunch of warnings they cannot do anything about apart
> >>>> from
> >>>>>>>> suppressing.
> >>>>>>>>
> >>>>>>>> Ismael
> >>>>>>>>
> >>>>>>>> On Fri, Jun 21, 2019 at 4:00 AM Andy Coates <an...@confluent.io>
> >>>> wrote:
> >>>>>>>>
> >>>>>>>>> Hi Ismael,
> >>>>>>>>>
> >>>>>>>>> I’m happy enough to not deprecate the existing `AdminClient`
> >>>> class as
> >>>>>>> part
> >>>>>>>>> of this change.
> >>>>>>>>>
> >>>>>>>>> However, note that, the class will likely be empty, i.e. all
> >>>> methods and
> >>>>>>>>> implementations will be inherited from the interface:
> >>>>>>>>>
> >>>>>>>>> public abstract class AdminClient implements Admin {
> >>>>>>>>> }
> >>>>>>>>>
> >>>>>>>>> Not marking it as deprecated has the benefit that users won’t see
> >>>> any
> >>>>>>>>> deprecation warnings on the next release. Conversely, deprecating
> >>>> it
> >>>>>>> will
> >>>>>>>>> mean we can choose to remove this, now pointless class, in the
> >>>> future
> >>>>>>> if we
> >>>>>>>>> choose.
> >>>>>>>>>
> >>>>>>>>> That’s my thinking for deprecation, but as I’ve said I’m happy
> >>>> either
> >>>>>>> way.
> >>>>>>>>>
> >>>>>>>>> Andy
> >>>>>>>>>
> >>>>>>>>>> On 18 Jun 2019, at 16:09, Ismael Juma <is...@juma.me.uk> wrote:
> >>>>>>>>>>
> >>>>>>>>>> I agree with Ryanne, I think we should avoid deprecating
> >>>> AdminClient
> >>>>>>> and
> >>>>>>>>>> causing so much churn for users who don't actually care about
> >>>> this
> >>>>>>> niche
> >>>>>>>>>> use case.
> >>>>>>>>>>
> >>>>>>>>>> Ismael
> >>>>>>>>>>
> >>>>>>>>>> On Tue, Jun 18, 2019 at 6:43 AM Andy Coates <an...@confluent.io>
> >>>> wrote:
> >>>>>>>>>>
> >>>>>>>>>>> Hi Ryanne,
> >>>>>>>>>>>
> >>>>>>>>>>> If we don't change the client code, then everywhere will still
> >>>> expect
> >>>>>>>>>>> subclasses of `AdminClient`, so the interface will be of no
> >>>> use, i.e.
> >>>>>>> I
> >>>>>>>>>>> can't write a class that implements the new interface and pass
> >>>> it to
> >>>>>>> the
> >>>>>>>>>>> client code.
> >>>>>>>>>>>
> >>>>>>>>>>> Thanks,
> >>>>>>>>>>>
> >>>>>>>>>>> Andy
> >>>>>>>>>>>
> >>>>>>>>>>> On Mon, 17 Jun 2019 at 19:01, Ryanne Dolan <
> >>>> ryannedolan@gmail.com>
> >>>>>>>>> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>>> Andy, while I agree that the new interface is useful, I'm not
> >>>>>>> convinced
> >>>>>>>>>>>> adding an interface requires deprecating AdminClient and
> >>>> changing so
> >>>>>>>>> much
> >>>>>>>>>>>> client code. Why not just add the Admin interface, have
> >>>> AdminClient
> >>>>>>>>>>>> implement it, and have done?
> >>>>>>>>>>>>
> >>>>>>>>>>>> Ryanne
> >>>>>>>>>>>>
> >>>>>>>>>>>> On Mon, Jun 17, 2019 at 12:09 PM Andy Coates <
> >>>> andy@confluent.io>
> >>>>>>>>> wrote:
> >>>>>>>>>>>>
> >>>>>>>>>>>>> Hi all,
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> I think I've addressed all concerns. Let me know if I've
> >>>> not.  Can I
> >>>>>>>>>>> call
> >>>>>>>>>>>>> another round of votes please?
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Thanks,
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Andy
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> On Fri, 14 Jun 2019 at 04:55, Satish Duggana <
> >>>>>>>>> satish.duggana@gmail.com
> >>>>>>>>>>>>
> >>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> Hi Andy,
> >>>>>>>>>>>>>> Thanks for the KIP. This is a good change and it gives the
> >>>> user a
> >>>>>>>>>>>> better
> >>>>>>>>>>>>>> handle on Admin client usage. I agree with the proposal
> >>>> except the
> >>>>>>>>>>> new
> >>>>>>>>>>>>>> `Admin` interface having all the methods from `AdminClient`
> >>>>>>> abstract
> >>>>>>>>>>>>> class.
> >>>>>>>>>>>>>> It should be kept clean having only the admin operations as
> >>>> methods
> >>>>>>>>>>>> from
> >>>>>>>>>>>>>> KafkaClient abstract class but not the factory methods as
> >>>> mentioned
> >>>>>>>>>>> in
> >>>>>>>>>>>>> the
> >>>>>>>>>>>>>> earlier mail.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> I know about dynamic proxies(which were widely used in
> >>>> RMI/EJB
> >>>>>>>>>>> world).
> >>>>>>>>>>>> I
> >>>>>>>>>>>>> am
> >>>>>>>>>>>>>> curious about the usecase using dynamic proxies with Admin
> >>>> client
> >>>>>>>>>>>>>> interface. Dynamic proxy can have performance penalty if it
> >>>> is used
> >>>>>>>>>>> in
> >>>>>>>>>>>>>> critical path. Is that the primary motivation for creating
> >>>> the KIP?
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Thanks,
> >>>>>>>>>>>>>> Satish.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> On Wed, Jun 12, 2019 at 8:43 PM Andy Coates <
> >>>> andy@confluent.io>
> >>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> I'm not married to that part.  That was only done to keep
> >>>> it more
> >>>>>>>>>>> or
> >>>>>>>>>>>>> less
> >>>>>>>>>>>>>>> inline with what's already there, (an abstract class that
> >>>> has a
> >>>>>>>>>>>> factory
> >>>>>>>>>>>>>>> method that returns a subclass.... sounds like the same
> >>>>>>>>>>> anti-pattern
> >>>>>>>>>>>>> ;))
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> An alternative would to have an `AdminClients` utility
> >>>> class to
> >>>>>>>>>>>> create
> >>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>> admin client.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> On Mon, 10 Jun 2019 at 19:31, Matthias J. Sax <
> >>>>>>>>>>> matthias@confluent.io
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Hmmm...
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> So the new interface, returns an instance of a class that
> >>>>>>>>>>>> implements
> >>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>> interface. This sounds a little bit like an anti-pattern?
> >>>>>>>>>>> Shouldn't
> >>>>>>>>>>>>>>>> interfaces actually not know anything about classes that
> >>>>>>>>>>> implement
> >>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>> interface?
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> -Matthias
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> On 6/10/19 11:22 AM, Andy Coates wrote:
> >>>>>>>>>>>>>>>>> `AdminClient` would be deprecated purely because it would
> >>>> no
> >>>>>>>>>>>> longer
> >>>>>>>>>>>>>>> serve
> >>>>>>>>>>>>>>>>> any purpose and would be virtually empty, getting all of
> >>>> its
> >>>>>>>>>>>>>>>> implementation
> >>>>>>>>>>>>>>>>> from the new interfar. It would be nice to remove this
> >>>> from the
> >>>>>>>>>>>> API
> >>>>>>>>>>>>>> at
> >>>>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>> next major version bump, hence the need to deprecate.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> `AdminClient.create()` would return what it does today,
> >>>> (so
> >>>>>>>>>>> not a
> >>>>>>>>>>>>>>>> breaking
> >>>>>>>>>>>>>>>>> change).
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> On Tue, 4 Jun 2019 at 22:24, Ryanne Dolan <
> >>>>>>>>>>> ryannedolan@gmail.com
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> The existing `AdminClient` will be marked as deprecated.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> What's the reasoning behind this? I'm fine with the other
> >>>>>>>>>>>> changes,
> >>>>>>>>>>>>>> but
> >>>>>>>>>>>>>>>>>> would prefer to keep the existing public API intact if
> >>>> it's
> >>>>>>>>>>> not
> >>>>>>>>>>>>>>> hurting
> >>>>>>>>>>>>>>>>>> anything.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Also, what will AdminClient.create() return? Would it be
> >>>> a
> >>>>>>>>>>>>> breaking
> >>>>>>>>>>>>>>>> change?
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Ryanne
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> On Tue, Jun 4, 2019, 11:17 AM Andy Coates <
> >>>> andy@confluent.io>
> >>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> Hi folks
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> As there's been no chatter on this KIP I'm assuming it's
> >>>>>>>>>>>>>>>> non-contentious,
> >>>>>>>>>>>>>>>>>>> (or just boring), hence I'd like to call a vote for
> >>>> KIP-476:
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>
> >>>>>>>
> >>>>
> >> https://cwiki.apache.org/confluence/display/KAFKA/KIP-476%3A+Add+Java+AdminClient+Interface
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> Thanks,
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> Andy
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>
> >>>
> >>
> >>
> > 
> 
> 
> Attachments:
> * signature.asc

Re: [VOTE] KIP-476: Add Java AdminClient interface

Posted by "Matthias J. Sax" <ma...@confluent.io>.

Not sure, if I understand the argument?

Why would anyone need to support multiple client side versions?
Clients/brokers are forward/backward compatible anyway.

Also, if one really supports multiple client side versions, won't they
use multiple shaded dependencies for different versions?

Last, it's possible to suppress warnings (at least in Java).

Can you elaborate?

IMHO, just adding a statement to JavaDocs is a little weak, and at some
point, we need to deprecate those methods anyway if we ever want to
remove them. The earlier we deprecate them, the earlier we can remove them.


-Matthias

On 7/1/19 4:22 AM, Andy Coates wrote:
> Done. I've not deprecated the factory methods on the AdminClient for the
> same reason the AdminClient itself is not deprecated, i.e. this would cause
> unavoidable warnings for libraries / platforms that support multiple
> versions of Kafka. However, I think we add a note to the Java docs of
> `AdminClient` to indicate that its use, going forward, is discouraged in
> favour of the new `Admin` interface and explain why its not  been
> deprecated, but that it may/will be removed in a future version.
> 
> Regarding factory methods on interfaces: there seems to be some difference
> of opinion here. I'm not sure of the best approach to revolve this. At the
> moment the KIP has factory methods on the new `Admin` interface, rather
> than some utility class. I prefer the utility class, but this isn't inline
> with the patterns in the code base and some of the core team have expressed
> they'd prefer to continue to have the factory methods on the interface.
> I'm happy with this if others are.
> 
> Thanks,
> 
> Andy
> 
> On Thu, 27 Jun 2019 at 23:21, Matthias J. Sax <ma...@confluent.io> wrote:
> 
>> @Andy:
>>
>> What about the factory methods of `AdminClient` class? Should they be
>> deprecated?
>>
>> One nit about the KIP: can you maybe insert "code blocks" to highlight
>> the API changes? Code blocks would simplify to read the KIP a lot.
>>
>>
>> -Matthias
>>
>> On 6/26/19 6:56 AM, Ryanne Dolan wrote:
>>> +1 (non-binding)
>>>
>>> Thanks.
>>> Ryanne
>>>
>>> On Tue, Jun 25, 2019 at 10:21 PM Satish Duggana <
>> satish.duggana@gmail.com>
>>> wrote:
>>>
>>>> +1 (non-binding)
>>>>
>>>> On Wed, Jun 26, 2019 at 8:37 AM Satish Duggana <
>> satish.duggana@gmail.com>
>>>> wrote:
>>>>>
>>>>> +1 Matthias/Andy.
>>>>> IMHO, interface is about the contract, it should not have/expose any
>>>>> implementation. I am fine with either way as it is more of taste or
>>>>> preference.
>>>>>
>>>>> Agree with Ismael/Colin/Ryanne on not deprecating for good reasons.
>>>>>
>>>>>
>>>>> On Mon, Jun 24, 2019 at 8:33 PM Andy Coates <an...@confluent.io> wrote:
>>>>>>
>>>>>> I agree Matthias.
>>>>>>
>>>>>> (In Scala, such factory methods are on a companion object. As Java
>>>> doesn't
>>>>>> have the concept of a companion object, an equivalent would be a
>>>> utility
>>>>>> class with a similar name...)
>>>>>>
>>>>>> However, I'll update the KIP to include the factory method on the
>>>> interface.
>>>>>>
>>>>>> On Fri, 21 Jun 2019 at 23:40, Matthias J. Sax <ma...@confluent.io>
>>>> wrote:
>>>>>>
>>>>>>> I still think, that an interface does not need to know anything about
>>>>>>> its implementation. But I am also fine if we add a factory method to
>>>> the
>>>>>>> new interface if that is preferred by most people.
>>>>>>>
>>>>>>>
>>>>>>> -Matthias
>>>>>>>
>>>>>>> On 6/21/19 7:10 AM, Ismael Juma wrote:
>>>>>>>> This is even more reason not to deprecate immediately, there is
>>>> very
>>>>>>> little
>>>>>>>> maintenance cost for us. We should be mindful that many of our
>>>> users (eg
>>>>>>>> Spark, Flink, etc.) typically allow users to specify the kafka
>>>> clients
>>>>>>>> version and hence avoid using new classes/interfaces for some
>>>> time. They
>>>>>>>> would get a bunch of warnings they cannot do anything about apart
>>>> from
>>>>>>>> suppressing.
>>>>>>>>
>>>>>>>> Ismael
>>>>>>>>
>>>>>>>> On Fri, Jun 21, 2019 at 4:00 AM Andy Coates <an...@confluent.io>
>>>> wrote:
>>>>>>>>
>>>>>>>>> Hi Ismael,
>>>>>>>>>
>>>>>>>>> I’m happy enough to not deprecate the existing `AdminClient`
>>>> class as
>>>>>>> part
>>>>>>>>> of this change.
>>>>>>>>>
>>>>>>>>> However, note that, the class will likely be empty, i.e. all
>>>> methods and
>>>>>>>>> implementations will be inherited from the interface:
>>>>>>>>>
>>>>>>>>> public abstract class AdminClient implements Admin {
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> Not marking it as deprecated has the benefit that users won’t see
>>>> any
>>>>>>>>> deprecation warnings on the next release. Conversely, deprecating
>>>> it
>>>>>>> will
>>>>>>>>> mean we can choose to remove this, now pointless class, in the
>>>> future
>>>>>>> if we
>>>>>>>>> choose.
>>>>>>>>>
>>>>>>>>> That’s my thinking for deprecation, but as I’ve said I’m happy
>>>> either
>>>>>>> way.
>>>>>>>>>
>>>>>>>>> Andy
>>>>>>>>>
>>>>>>>>>> On 18 Jun 2019, at 16:09, Ismael Juma <is...@juma.me.uk> wrote:
>>>>>>>>>>
>>>>>>>>>> I agree with Ryanne, I think we should avoid deprecating
>>>> AdminClient
>>>>>>> and
>>>>>>>>>> causing so much churn for users who don't actually care about
>>>> this
>>>>>>> niche
>>>>>>>>>> use case.
>>>>>>>>>>
>>>>>>>>>> Ismael
>>>>>>>>>>
>>>>>>>>>> On Tue, Jun 18, 2019 at 6:43 AM Andy Coates <an...@confluent.io>
>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> Hi Ryanne,
>>>>>>>>>>>
>>>>>>>>>>> If we don't change the client code, then everywhere will still
>>>> expect
>>>>>>>>>>> subclasses of `AdminClient`, so the interface will be of no
>>>> use, i.e.
>>>>>>> I
>>>>>>>>>>> can't write a class that implements the new interface and pass
>>>> it to
>>>>>>> the
>>>>>>>>>>> client code.
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>>
>>>>>>>>>>> Andy
>>>>>>>>>>>
>>>>>>>>>>> On Mon, 17 Jun 2019 at 19:01, Ryanne Dolan <
>>>> ryannedolan@gmail.com>
>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Andy, while I agree that the new interface is useful, I'm not
>>>>>>> convinced
>>>>>>>>>>>> adding an interface requires deprecating AdminClient and
>>>> changing so
>>>>>>>>> much
>>>>>>>>>>>> client code. Why not just add the Admin interface, have
>>>> AdminClient
>>>>>>>>>>>> implement it, and have done?
>>>>>>>>>>>>
>>>>>>>>>>>> Ryanne
>>>>>>>>>>>>
>>>>>>>>>>>> On Mon, Jun 17, 2019 at 12:09 PM Andy Coates <
>>>> andy@confluent.io>
>>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Hi all,
>>>>>>>>>>>>>
>>>>>>>>>>>>> I think I've addressed all concerns. Let me know if I've
>>>> not.  Can I
>>>>>>>>>>> call
>>>>>>>>>>>>> another round of votes please?
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>
>>>>>>>>>>>>> Andy
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Fri, 14 Jun 2019 at 04:55, Satish Duggana <
>>>>>>>>> satish.duggana@gmail.com
>>>>>>>>>>>>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Hi Andy,
>>>>>>>>>>>>>> Thanks for the KIP. This is a good change and it gives the
>>>> user a
>>>>>>>>>>>> better
>>>>>>>>>>>>>> handle on Admin client usage. I agree with the proposal
>>>> except the
>>>>>>>>>>> new
>>>>>>>>>>>>>> `Admin` interface having all the methods from `AdminClient`
>>>>>>> abstract
>>>>>>>>>>>>> class.
>>>>>>>>>>>>>> It should be kept clean having only the admin operations as
>>>> methods
>>>>>>>>>>>> from
>>>>>>>>>>>>>> KafkaClient abstract class but not the factory methods as
>>>> mentioned
>>>>>>>>>>> in
>>>>>>>>>>>>> the
>>>>>>>>>>>>>> earlier mail.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I know about dynamic proxies(which were widely used in
>>>> RMI/EJB
>>>>>>>>>>> world).
>>>>>>>>>>>> I
>>>>>>>>>>>>> am
>>>>>>>>>>>>>> curious about the usecase using dynamic proxies with Admin
>>>> client
>>>>>>>>>>>>>> interface. Dynamic proxy can have performance penalty if it
>>>> is used
>>>>>>>>>>> in
>>>>>>>>>>>>>> critical path. Is that the primary motivation for creating
>>>> the KIP?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>> Satish.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Wed, Jun 12, 2019 at 8:43 PM Andy Coates <
>>>> andy@confluent.io>
>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I'm not married to that part.  That was only done to keep
>>>> it more
>>>>>>>>>>> or
>>>>>>>>>>>>> less
>>>>>>>>>>>>>>> inline with what's already there, (an abstract class that
>>>> has a
>>>>>>>>>>>> factory
>>>>>>>>>>>>>>> method that returns a subclass.... sounds like the same
>>>>>>>>>>> anti-pattern
>>>>>>>>>>>>> ;))
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> An alternative would to have an `AdminClients` utility
>>>> class to
>>>>>>>>>>>> create
>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>> admin client.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Mon, 10 Jun 2019 at 19:31, Matthias J. Sax <
>>>>>>>>>>> matthias@confluent.io
>>>>>>>>>>>>>
>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Hmmm...
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> So the new interface, returns an instance of a class that
>>>>>>>>>>>> implements
>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>> interface. This sounds a little bit like an anti-pattern?
>>>>>>>>>>> Shouldn't
>>>>>>>>>>>>>>>> interfaces actually not know anything about classes that
>>>>>>>>>>> implement
>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>> interface?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> -Matthias
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 6/10/19 11:22 AM, Andy Coates wrote:
>>>>>>>>>>>>>>>>> `AdminClient` would be deprecated purely because it would
>>>> no
>>>>>>>>>>>> longer
>>>>>>>>>>>>>>> serve
>>>>>>>>>>>>>>>>> any purpose and would be virtually empty, getting all of
>>>> its
>>>>>>>>>>>>>>>> implementation
>>>>>>>>>>>>>>>>> from the new interfar. It would be nice to remove this
>>>> from the
>>>>>>>>>>>> API
>>>>>>>>>>>>>> at
>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>> next major version bump, hence the need to deprecate.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> `AdminClient.create()` would return what it does today,
>>>> (so
>>>>>>>>>>> not a
>>>>>>>>>>>>>>>> breaking
>>>>>>>>>>>>>>>>> change).
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On Tue, 4 Jun 2019 at 22:24, Ryanne Dolan <
>>>>>>>>>>> ryannedolan@gmail.com
>>>>>>>>>>>>>
>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> The existing `AdminClient` will be marked as deprecated.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> What's the reasoning behind this? I'm fine with the other
>>>>>>>>>>>> changes,
>>>>>>>>>>>>>> but
>>>>>>>>>>>>>>>>>> would prefer to keep the existing public API intact if
>>>> it's
>>>>>>>>>>> not
>>>>>>>>>>>>>>> hurting
>>>>>>>>>>>>>>>>>> anything.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Also, what will AdminClient.create() return? Would it be
>>>> a
>>>>>>>>>>>>> breaking
>>>>>>>>>>>>>>>> change?
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Ryanne
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On Tue, Jun 4, 2019, 11:17 AM Andy Coates <
>>>> andy@confluent.io>
>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Hi folks
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> As there's been no chatter on this KIP I'm assuming it's
>>>>>>>>>>>>>>>> non-contentious,
>>>>>>>>>>>>>>>>>>> (or just boring), hence I'd like to call a vote for
>>>> KIP-476:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>
>> https://cwiki.apache.org/confluence/display/KAFKA/KIP-476%3A+Add+Java+AdminClient+Interface
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Andy
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>
>>>
>>
>>
>

Re: [VOTE] KIP-476: Add Java AdminClient interface

Posted by Andy Coates <an...@confluent.io>.

Done. I've not deprecated the factory methods on the AdminClient for the
same reason the AdminClient itself is not deprecated, i.e. this would cause
unavoidable warnings for libraries / platforms that support multiple
versions of Kafka. However, I think we add a note to the Java docs of
`AdminClient` to indicate that its use, going forward, is discouraged in
favour of the new `Admin` interface and explain why its not  been
deprecated, but that it may/will be removed in a future version.

Regarding factory methods on interfaces: there seems to be some difference
of opinion here. I'm not sure of the best approach to revolve this. At the
moment the KIP has factory methods on the new `Admin` interface, rather
than some utility class. I prefer the utility class, but this isn't inline
with the patterns in the code base and some of the core team have expressed
they'd prefer to continue to have the factory methods on the interface.
I'm happy with this if others are.

Thanks,

Andy

On Thu, 27 Jun 2019 at 23:21, Matthias J. Sax <ma...@confluent.io> wrote:

> @Andy:
>
> What about the factory methods of `AdminClient` class? Should they be
> deprecated?
>
> One nit about the KIP: can you maybe insert "code blocks" to highlight
> the API changes? Code blocks would simplify to read the KIP a lot.
>
>
> -Matthias
>
> On 6/26/19 6:56 AM, Ryanne Dolan wrote:
> > +1 (non-binding)
> >
> > Thanks.
> > Ryanne
> >
> > On Tue, Jun 25, 2019 at 10:21 PM Satish Duggana <
> satish.duggana@gmail.com>
> > wrote:
> >
> >> +1 (non-binding)
> >>
> >> On Wed, Jun 26, 2019 at 8:37 AM Satish Duggana <
> satish.duggana@gmail.com>
> >> wrote:
> >>>
> >>> +1 Matthias/Andy.
> >>> IMHO, interface is about the contract, it should not have/expose any
> >>> implementation. I am fine with either way as it is more of taste or
> >>> preference.
> >>>
> >>> Agree with Ismael/Colin/Ryanne on not deprecating for good reasons.
> >>>
> >>>
> >>> On Mon, Jun 24, 2019 at 8:33 PM Andy Coates <an...@confluent.io> wrote:
> >>>>
> >>>> I agree Matthias.
> >>>>
> >>>> (In Scala, such factory methods are on a companion object. As Java
> >> doesn't
> >>>> have the concept of a companion object, an equivalent would be a
> >> utility
> >>>> class with a similar name...)
> >>>>
> >>>> However, I'll update the KIP to include the factory method on the
> >> interface.
> >>>>
> >>>> On Fri, 21 Jun 2019 at 23:40, Matthias J. Sax <ma...@confluent.io>
> >> wrote:
> >>>>
> >>>>> I still think, that an interface does not need to know anything about
> >>>>> its implementation. But I am also fine if we add a factory method to
> >> the
> >>>>> new interface if that is preferred by most people.
> >>>>>
> >>>>>
> >>>>> -Matthias
> >>>>>
> >>>>> On 6/21/19 7:10 AM, Ismael Juma wrote:
> >>>>>> This is even more reason not to deprecate immediately, there is
> >> very
> >>>>> little
> >>>>>> maintenance cost for us. We should be mindful that many of our
> >> users (eg
> >>>>>> Spark, Flink, etc.) typically allow users to specify the kafka
> >> clients
> >>>>>> version and hence avoid using new classes/interfaces for some
> >> time. They
> >>>>>> would get a bunch of warnings they cannot do anything about apart
> >> from
> >>>>>> suppressing.
> >>>>>>
> >>>>>> Ismael
> >>>>>>
> >>>>>> On Fri, Jun 21, 2019 at 4:00 AM Andy Coates <an...@confluent.io>
> >> wrote:
> >>>>>>
> >>>>>>> Hi Ismael,
> >>>>>>>
> >>>>>>> I’m happy enough to not deprecate the existing `AdminClient`
> >> class as
> >>>>> part
> >>>>>>> of this change.
> >>>>>>>
> >>>>>>> However, note that, the class will likely be empty, i.e. all
> >> methods and
> >>>>>>> implementations will be inherited from the interface:
> >>>>>>>
> >>>>>>> public abstract class AdminClient implements Admin {
> >>>>>>> }
> >>>>>>>
> >>>>>>> Not marking it as deprecated has the benefit that users won’t see
> >> any
> >>>>>>> deprecation warnings on the next release. Conversely, deprecating
> >> it
> >>>>> will
> >>>>>>> mean we can choose to remove this, now pointless class, in the
> >> future
> >>>>> if we
> >>>>>>> choose.
> >>>>>>>
> >>>>>>> That’s my thinking for deprecation, but as I’ve said I’m happy
> >> either
> >>>>> way.
> >>>>>>>
> >>>>>>> Andy
> >>>>>>>
> >>>>>>>> On 18 Jun 2019, at 16:09, Ismael Juma <is...@juma.me.uk> wrote:
> >>>>>>>>
> >>>>>>>> I agree with Ryanne, I think we should avoid deprecating
> >> AdminClient
> >>>>> and
> >>>>>>>> causing so much churn for users who don't actually care about
> >> this
> >>>>> niche
> >>>>>>>> use case.
> >>>>>>>>
> >>>>>>>> Ismael
> >>>>>>>>
> >>>>>>>> On Tue, Jun 18, 2019 at 6:43 AM Andy Coates <an...@confluent.io>
> >> wrote:
> >>>>>>>>
> >>>>>>>>> Hi Ryanne,
> >>>>>>>>>
> >>>>>>>>> If we don't change the client code, then everywhere will still
> >> expect
> >>>>>>>>> subclasses of `AdminClient`, so the interface will be of no
> >> use, i.e.
> >>>>> I
> >>>>>>>>> can't write a class that implements the new interface and pass
> >> it to
> >>>>> the
> >>>>>>>>> client code.
> >>>>>>>>>
> >>>>>>>>> Thanks,
> >>>>>>>>>
> >>>>>>>>> Andy
> >>>>>>>>>
> >>>>>>>>> On Mon, 17 Jun 2019 at 19:01, Ryanne Dolan <
> >> ryannedolan@gmail.com>
> >>>>>>> wrote:
> >>>>>>>>>
> >>>>>>>>>> Andy, while I agree that the new interface is useful, I'm not
> >>>>> convinced
> >>>>>>>>>> adding an interface requires deprecating AdminClient and
> >> changing so
> >>>>>>> much
> >>>>>>>>>> client code. Why not just add the Admin interface, have
> >> AdminClient
> >>>>>>>>>> implement it, and have done?
> >>>>>>>>>>
> >>>>>>>>>> Ryanne
> >>>>>>>>>>
> >>>>>>>>>> On Mon, Jun 17, 2019 at 12:09 PM Andy Coates <
> >> andy@confluent.io>
> >>>>>>> wrote:
> >>>>>>>>>>
> >>>>>>>>>>> Hi all,
> >>>>>>>>>>>
> >>>>>>>>>>> I think I've addressed all concerns. Let me know if I've
> >> not.  Can I
> >>>>>>>>> call
> >>>>>>>>>>> another round of votes please?
> >>>>>>>>>>>
> >>>>>>>>>>> Thanks,
> >>>>>>>>>>>
> >>>>>>>>>>> Andy
> >>>>>>>>>>>
> >>>>>>>>>>> On Fri, 14 Jun 2019 at 04:55, Satish Duggana <
> >>>>>>> satish.duggana@gmail.com
> >>>>>>>>>>
> >>>>>>>>>>> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>>> Hi Andy,
> >>>>>>>>>>>> Thanks for the KIP. This is a good change and it gives the
> >> user a
> >>>>>>>>>> better
> >>>>>>>>>>>> handle on Admin client usage. I agree with the proposal
> >> except the
> >>>>>>>>> new
> >>>>>>>>>>>> `Admin` interface having all the methods from `AdminClient`
> >>>>> abstract
> >>>>>>>>>>> class.
> >>>>>>>>>>>> It should be kept clean having only the admin operations as
> >> methods
> >>>>>>>>>> from
> >>>>>>>>>>>> KafkaClient abstract class but not the factory methods as
> >> mentioned
> >>>>>>>>> in
> >>>>>>>>>>> the
> >>>>>>>>>>>> earlier mail.
> >>>>>>>>>>>>
> >>>>>>>>>>>> I know about dynamic proxies(which were widely used in
> >> RMI/EJB
> >>>>>>>>> world).
> >>>>>>>>>> I
> >>>>>>>>>>> am
> >>>>>>>>>>>> curious about the usecase using dynamic proxies with Admin
> >> client
> >>>>>>>>>>>> interface. Dynamic proxy can have performance penalty if it
> >> is used
> >>>>>>>>> in
> >>>>>>>>>>>> critical path. Is that the primary motivation for creating
> >> the KIP?
> >>>>>>>>>>>>
> >>>>>>>>>>>> Thanks,
> >>>>>>>>>>>> Satish.
> >>>>>>>>>>>>
> >>>>>>>>>>>> On Wed, Jun 12, 2019 at 8:43 PM Andy Coates <
> >> andy@confluent.io>
> >>>>>>>>> wrote:
> >>>>>>>>>>>>
> >>>>>>>>>>>>> I'm not married to that part.  That was only done to keep
> >> it more
> >>>>>>>>> or
> >>>>>>>>>>> less
> >>>>>>>>>>>>> inline with what's already there, (an abstract class that
> >> has a
> >>>>>>>>>> factory
> >>>>>>>>>>>>> method that returns a subclass.... sounds like the same
> >>>>>>>>> anti-pattern
> >>>>>>>>>>> ;))
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> An alternative would to have an `AdminClients` utility
> >> class to
> >>>>>>>>>> create
> >>>>>>>>>>>> the
> >>>>>>>>>>>>> admin client.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> On Mon, 10 Jun 2019 at 19:31, Matthias J. Sax <
> >>>>>>>>> matthias@confluent.io
> >>>>>>>>>>>
> >>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> Hmmm...
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> So the new interface, returns an instance of a class that
> >>>>>>>>>> implements
> >>>>>>>>>>>> the
> >>>>>>>>>>>>>> interface. This sounds a little bit like an anti-pattern?
> >>>>>>>>> Shouldn't
> >>>>>>>>>>>>>> interfaces actually not know anything about classes that
> >>>>>>>>> implement
> >>>>>>>>>>> the
> >>>>>>>>>>>>>> interface?
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> -Matthias
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> On 6/10/19 11:22 AM, Andy Coates wrote:
> >>>>>>>>>>>>>>> `AdminClient` would be deprecated purely because it would
> >> no
> >>>>>>>>>> longer
> >>>>>>>>>>>>> serve
> >>>>>>>>>>>>>>> any purpose and would be virtually empty, getting all of
> >> its
> >>>>>>>>>>>>>> implementation
> >>>>>>>>>>>>>>> from the new interfar. It would be nice to remove this
> >> from the
> >>>>>>>>>> API
> >>>>>>>>>>>> at
> >>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>> next major version bump, hence the need to deprecate.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> `AdminClient.create()` would return what it does today,
> >> (so
> >>>>>>>>> not a
> >>>>>>>>>>>>>> breaking
> >>>>>>>>>>>>>>> change).
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> On Tue, 4 Jun 2019 at 22:24, Ryanne Dolan <
> >>>>>>>>> ryannedolan@gmail.com
> >>>>>>>>>>>
> >>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> The existing `AdminClient` will be marked as deprecated.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> What's the reasoning behind this? I'm fine with the other
> >>>>>>>>>> changes,
> >>>>>>>>>>>> but
> >>>>>>>>>>>>>>>> would prefer to keep the existing public API intact if
> >> it's
> >>>>>>>>> not
> >>>>>>>>>>>>> hurting
> >>>>>>>>>>>>>>>> anything.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Also, what will AdminClient.create() return? Would it be
> >> a
> >>>>>>>>>>> breaking
> >>>>>>>>>>>>>> change?
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Ryanne
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> On Tue, Jun 4, 2019, 11:17 AM Andy Coates <
> >> andy@confluent.io>
> >>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Hi folks
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> As there's been no chatter on this KIP I'm assuming it's
> >>>>>>>>>>>>>> non-contentious,
> >>>>>>>>>>>>>>>>> (or just boring), hence I'd like to call a vote for
> >> KIP-476:
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>
> >>>>>
> >>
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-476%3A+Add+Java+AdminClient+Interface
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Thanks,
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Andy
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>
> >
>
>

Re: [VOTE] KIP-476: Add Java AdminClient interface

Posted by "Matthias J. Sax" <ma...@confluent.io>.

@Andy:

What about the factory methods of `AdminClient` class? Should they be
deprecated?

One nit about the KIP: can you maybe insert "code blocks" to highlight
the API changes? Code blocks would simplify to read the KIP a lot.


-Matthias

On 6/26/19 6:56 AM, Ryanne Dolan wrote:
> +1 (non-binding)
> 
> Thanks.
> Ryanne
> 
> On Tue, Jun 25, 2019 at 10:21 PM Satish Duggana <sa...@gmail.com>
> wrote:
> 
>> +1 (non-binding)
>>
>> On Wed, Jun 26, 2019 at 8:37 AM Satish Duggana <sa...@gmail.com>
>> wrote:
>>>
>>> +1 Matthias/Andy.
>>> IMHO, interface is about the contract, it should not have/expose any
>>> implementation. I am fine with either way as it is more of taste or
>>> preference.
>>>
>>> Agree with Ismael/Colin/Ryanne on not deprecating for good reasons.
>>>
>>>
>>> On Mon, Jun 24, 2019 at 8:33 PM Andy Coates <an...@confluent.io> wrote:
>>>>
>>>> I agree Matthias.
>>>>
>>>> (In Scala, such factory methods are on a companion object. As Java
>> doesn't
>>>> have the concept of a companion object, an equivalent would be a
>> utility
>>>> class with a similar name...)
>>>>
>>>> However, I'll update the KIP to include the factory method on the
>> interface.
>>>>
>>>> On Fri, 21 Jun 2019 at 23:40, Matthias J. Sax <ma...@confluent.io>
>> wrote:
>>>>
>>>>> I still think, that an interface does not need to know anything about
>>>>> its implementation. But I am also fine if we add a factory method to
>> the
>>>>> new interface if that is preferred by most people.
>>>>>
>>>>>
>>>>> -Matthias
>>>>>
>>>>> On 6/21/19 7:10 AM, Ismael Juma wrote:
>>>>>> This is even more reason not to deprecate immediately, there is
>> very
>>>>> little
>>>>>> maintenance cost for us. We should be mindful that many of our
>> users (eg
>>>>>> Spark, Flink, etc.) typically allow users to specify the kafka
>> clients
>>>>>> version and hence avoid using new classes/interfaces for some
>> time. They
>>>>>> would get a bunch of warnings they cannot do anything about apart
>> from
>>>>>> suppressing.
>>>>>>
>>>>>> Ismael
>>>>>>
>>>>>> On Fri, Jun 21, 2019 at 4:00 AM Andy Coates <an...@confluent.io>
>> wrote:
>>>>>>
>>>>>>> Hi Ismael,
>>>>>>>
>>>>>>> I’m happy enough to not deprecate the existing `AdminClient`
>> class as
>>>>> part
>>>>>>> of this change.
>>>>>>>
>>>>>>> However, note that, the class will likely be empty, i.e. all
>> methods and
>>>>>>> implementations will be inherited from the interface:
>>>>>>>
>>>>>>> public abstract class AdminClient implements Admin {
>>>>>>> }
>>>>>>>
>>>>>>> Not marking it as deprecated has the benefit that users won’t see
>> any
>>>>>>> deprecation warnings on the next release. Conversely, deprecating
>> it
>>>>> will
>>>>>>> mean we can choose to remove this, now pointless class, in the
>> future
>>>>> if we
>>>>>>> choose.
>>>>>>>
>>>>>>> That’s my thinking for deprecation, but as I’ve said I’m happy
>> either
>>>>> way.
>>>>>>>
>>>>>>> Andy
>>>>>>>
>>>>>>>> On 18 Jun 2019, at 16:09, Ismael Juma <is...@juma.me.uk> wrote:
>>>>>>>>
>>>>>>>> I agree with Ryanne, I think we should avoid deprecating
>> AdminClient
>>>>> and
>>>>>>>> causing so much churn for users who don't actually care about
>> this
>>>>> niche
>>>>>>>> use case.
>>>>>>>>
>>>>>>>> Ismael
>>>>>>>>
>>>>>>>> On Tue, Jun 18, 2019 at 6:43 AM Andy Coates <an...@confluent.io>
>> wrote:
>>>>>>>>
>>>>>>>>> Hi Ryanne,
>>>>>>>>>
>>>>>>>>> If we don't change the client code, then everywhere will still
>> expect
>>>>>>>>> subclasses of `AdminClient`, so the interface will be of no
>> use, i.e.
>>>>> I
>>>>>>>>> can't write a class that implements the new interface and pass
>> it to
>>>>> the
>>>>>>>>> client code.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>>
>>>>>>>>> Andy
>>>>>>>>>
>>>>>>>>> On Mon, 17 Jun 2019 at 19:01, Ryanne Dolan <
>> ryannedolan@gmail.com>
>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> Andy, while I agree that the new interface is useful, I'm not
>>>>> convinced
>>>>>>>>>> adding an interface requires deprecating AdminClient and
>> changing so
>>>>>>> much
>>>>>>>>>> client code. Why not just add the Admin interface, have
>> AdminClient
>>>>>>>>>> implement it, and have done?
>>>>>>>>>>
>>>>>>>>>> Ryanne
>>>>>>>>>>
>>>>>>>>>> On Mon, Jun 17, 2019 at 12:09 PM Andy Coates <
>> andy@confluent.io>
>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> Hi all,
>>>>>>>>>>>
>>>>>>>>>>> I think I've addressed all concerns. Let me know if I've
>> not.  Can I
>>>>>>>>> call
>>>>>>>>>>> another round of votes please?
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>>
>>>>>>>>>>> Andy
>>>>>>>>>>>
>>>>>>>>>>> On Fri, 14 Jun 2019 at 04:55, Satish Duggana <
>>>>>>> satish.duggana@gmail.com
>>>>>>>>>>
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Hi Andy,
>>>>>>>>>>>> Thanks for the KIP. This is a good change and it gives the
>> user a
>>>>>>>>>> better
>>>>>>>>>>>> handle on Admin client usage. I agree with the proposal
>> except the
>>>>>>>>> new
>>>>>>>>>>>> `Admin` interface having all the methods from `AdminClient`
>>>>> abstract
>>>>>>>>>>> class.
>>>>>>>>>>>> It should be kept clean having only the admin operations as
>> methods
>>>>>>>>>> from
>>>>>>>>>>>> KafkaClient abstract class but not the factory methods as
>> mentioned
>>>>>>>>> in
>>>>>>>>>>> the
>>>>>>>>>>>> earlier mail.
>>>>>>>>>>>>
>>>>>>>>>>>> I know about dynamic proxies(which were widely used in
>> RMI/EJB
>>>>>>>>> world).
>>>>>>>>>> I
>>>>>>>>>>> am
>>>>>>>>>>>> curious about the usecase using dynamic proxies with Admin
>> client
>>>>>>>>>>>> interface. Dynamic proxy can have performance penalty if it
>> is used
>>>>>>>>> in
>>>>>>>>>>>> critical path. Is that the primary motivation for creating
>> the KIP?
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks,
>>>>>>>>>>>> Satish.
>>>>>>>>>>>>
>>>>>>>>>>>> On Wed, Jun 12, 2019 at 8:43 PM Andy Coates <
>> andy@confluent.io>
>>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> I'm not married to that part.  That was only done to keep
>> it more
>>>>>>>>> or
>>>>>>>>>>> less
>>>>>>>>>>>>> inline with what's already there, (an abstract class that
>> has a
>>>>>>>>>> factory
>>>>>>>>>>>>> method that returns a subclass.... sounds like the same
>>>>>>>>> anti-pattern
>>>>>>>>>>> ;))
>>>>>>>>>>>>>
>>>>>>>>>>>>> An alternative would to have an `AdminClients` utility
>> class to
>>>>>>>>>> create
>>>>>>>>>>>> the
>>>>>>>>>>>>> admin client.
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Mon, 10 Jun 2019 at 19:31, Matthias J. Sax <
>>>>>>>>> matthias@confluent.io
>>>>>>>>>>>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Hmmm...
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> So the new interface, returns an instance of a class that
>>>>>>>>>> implements
>>>>>>>>>>>> the
>>>>>>>>>>>>>> interface. This sounds a little bit like an anti-pattern?
>>>>>>>>> Shouldn't
>>>>>>>>>>>>>> interfaces actually not know anything about classes that
>>>>>>>>> implement
>>>>>>>>>>> the
>>>>>>>>>>>>>> interface?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> -Matthias
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 6/10/19 11:22 AM, Andy Coates wrote:
>>>>>>>>>>>>>>> `AdminClient` would be deprecated purely because it would
>> no
>>>>>>>>>> longer
>>>>>>>>>>>>> serve
>>>>>>>>>>>>>>> any purpose and would be virtually empty, getting all of
>> its
>>>>>>>>>>>>>> implementation
>>>>>>>>>>>>>>> from the new interfar. It would be nice to remove this
>> from the
>>>>>>>>>> API
>>>>>>>>>>>> at
>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>> next major version bump, hence the need to deprecate.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> `AdminClient.create()` would return what it does today,
>> (so
>>>>>>>>> not a
>>>>>>>>>>>>>> breaking
>>>>>>>>>>>>>>> change).
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Tue, 4 Jun 2019 at 22:24, Ryanne Dolan <
>>>>>>>>> ryannedolan@gmail.com
>>>>>>>>>>>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> The existing `AdminClient` will be marked as deprecated.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> What's the reasoning behind this? I'm fine with the other
>>>>>>>>>> changes,
>>>>>>>>>>>> but
>>>>>>>>>>>>>>>> would prefer to keep the existing public API intact if
>> it's
>>>>>>>>> not
>>>>>>>>>>>>> hurting
>>>>>>>>>>>>>>>> anything.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Also, what will AdminClient.create() return? Would it be
>> a
>>>>>>>>>>> breaking
>>>>>>>>>>>>>> change?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Ryanne
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On Tue, Jun 4, 2019, 11:17 AM Andy Coates <
>> andy@confluent.io>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Hi folks
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> As there's been no chatter on this KIP I'm assuming it's
>>>>>>>>>>>>>> non-contentious,
>>>>>>>>>>>>>>>>> (or just boring), hence I'd like to call a vote for
>> KIP-476:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>
>> https://cwiki.apache.org/confluence/display/KAFKA/KIP-476%3A+Add+Java+AdminClient+Interface
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Andy
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>
>

Re: [VOTE] KIP-476: Add Java AdminClient interface

Posted by Ryanne Dolan <ry...@gmail.com>.

+1 (non-binding)

Thanks.
Ryanne

On Tue, Jun 25, 2019 at 10:21 PM Satish Duggana <sa...@gmail.com>
wrote:

> +1 (non-binding)
>
> On Wed, Jun 26, 2019 at 8:37 AM Satish Duggana <sa...@gmail.com>
> wrote:
> >
> > +1 Matthias/Andy.
> > IMHO, interface is about the contract, it should not have/expose any
> > implementation. I am fine with either way as it is more of taste or
> > preference.
> >
> > Agree with Ismael/Colin/Ryanne on not deprecating for good reasons.
> >
> >
> > On Mon, Jun 24, 2019 at 8:33 PM Andy Coates <an...@confluent.io> wrote:
> > >
> > > I agree Matthias.
> > >
> > > (In Scala, such factory methods are on a companion object. As Java
> doesn't
> > > have the concept of a companion object, an equivalent would be a
> utility
> > > class with a similar name...)
> > >
> > > However, I'll update the KIP to include the factory method on the
> interface.
> > >
> > > On Fri, 21 Jun 2019 at 23:40, Matthias J. Sax <ma...@confluent.io>
> wrote:
> > >
> > > > I still think, that an interface does not need to know anything about
> > > > its implementation. But I am also fine if we add a factory method to
> the
> > > > new interface if that is preferred by most people.
> > > >
> > > >
> > > > -Matthias
> > > >
> > > > On 6/21/19 7:10 AM, Ismael Juma wrote:
> > > > > This is even more reason not to deprecate immediately, there is
> very
> > > > little
> > > > > maintenance cost for us. We should be mindful that many of our
> users (eg
> > > > > Spark, Flink, etc.) typically allow users to specify the kafka
> clients
> > > > > version and hence avoid using new classes/interfaces for some
> time. They
> > > > > would get a bunch of warnings they cannot do anything about apart
> from
> > > > > suppressing.
> > > > >
> > > > > Ismael
> > > > >
> > > > > On Fri, Jun 21, 2019 at 4:00 AM Andy Coates <an...@confluent.io>
> wrote:
> > > > >
> > > > >> Hi Ismael,
> > > > >>
> > > > >> I’m happy enough to not deprecate the existing `AdminClient`
> class as
> > > > part
> > > > >> of this change.
> > > > >>
> > > > >> However, note that, the class will likely be empty, i.e. all
> methods and
> > > > >> implementations will be inherited from the interface:
> > > > >>
> > > > >> public abstract class AdminClient implements Admin {
> > > > >> }
> > > > >>
> > > > >> Not marking it as deprecated has the benefit that users won’t see
> any
> > > > >> deprecation warnings on the next release. Conversely, deprecating
> it
> > > > will
> > > > >> mean we can choose to remove this, now pointless class, in the
> future
> > > > if we
> > > > >> choose.
> > > > >>
> > > > >> That’s my thinking for deprecation, but as I’ve said I’m happy
> either
> > > > way.
> > > > >>
> > > > >> Andy
> > > > >>
> > > > >>> On 18 Jun 2019, at 16:09, Ismael Juma <is...@juma.me.uk> wrote:
> > > > >>>
> > > > >>> I agree with Ryanne, I think we should avoid deprecating
> AdminClient
> > > > and
> > > > >>> causing so much churn for users who don't actually care about
> this
> > > > niche
> > > > >>> use case.
> > > > >>>
> > > > >>> Ismael
> > > > >>>
> > > > >>> On Tue, Jun 18, 2019 at 6:43 AM Andy Coates <an...@confluent.io>
> wrote:
> > > > >>>
> > > > >>>> Hi Ryanne,
> > > > >>>>
> > > > >>>> If we don't change the client code, then everywhere will still
> expect
> > > > >>>> subclasses of `AdminClient`, so the interface will be of no
> use, i.e.
> > > > I
> > > > >>>> can't write a class that implements the new interface and pass
> it to
> > > > the
> > > > >>>> client code.
> > > > >>>>
> > > > >>>> Thanks,
> > > > >>>>
> > > > >>>> Andy
> > > > >>>>
> > > > >>>> On Mon, 17 Jun 2019 at 19:01, Ryanne Dolan <
> ryannedolan@gmail.com>
> > > > >> wrote:
> > > > >>>>
> > > > >>>>> Andy, while I agree that the new interface is useful, I'm not
> > > > convinced
> > > > >>>>> adding an interface requires deprecating AdminClient and
> changing so
> > > > >> much
> > > > >>>>> client code. Why not just add the Admin interface, have
> AdminClient
> > > > >>>>> implement it, and have done?
> > > > >>>>>
> > > > >>>>> Ryanne
> > > > >>>>>
> > > > >>>>> On Mon, Jun 17, 2019 at 12:09 PM Andy Coates <
> andy@confluent.io>
> > > > >> wrote:
> > > > >>>>>
> > > > >>>>>> Hi all,
> > > > >>>>>>
> > > > >>>>>> I think I've addressed all concerns. Let me know if I've
> not.  Can I
> > > > >>>> call
> > > > >>>>>> another round of votes please?
> > > > >>>>>>
> > > > >>>>>> Thanks,
> > > > >>>>>>
> > > > >>>>>> Andy
> > > > >>>>>>
> > > > >>>>>> On Fri, 14 Jun 2019 at 04:55, Satish Duggana <
> > > > >> satish.duggana@gmail.com
> > > > >>>>>
> > > > >>>>>> wrote:
> > > > >>>>>>
> > > > >>>>>>> Hi Andy,
> > > > >>>>>>> Thanks for the KIP. This is a good change and it gives the
> user a
> > > > >>>>> better
> > > > >>>>>>> handle on Admin client usage. I agree with the proposal
> except the
> > > > >>>> new
> > > > >>>>>>> `Admin` interface having all the methods from `AdminClient`
> > > > abstract
> > > > >>>>>> class.
> > > > >>>>>>> It should be kept clean having only the admin operations as
> methods
> > > > >>>>> from
> > > > >>>>>>> KafkaClient abstract class but not the factory methods as
> mentioned
> > > > >>>> in
> > > > >>>>>> the
> > > > >>>>>>> earlier mail.
> > > > >>>>>>>
> > > > >>>>>>> I know about dynamic proxies(which were widely used in
> RMI/EJB
> > > > >>>> world).
> > > > >>>>> I
> > > > >>>>>> am
> > > > >>>>>>> curious about the usecase using dynamic proxies with Admin
> client
> > > > >>>>>>> interface. Dynamic proxy can have performance penalty if it
> is used
> > > > >>>> in
> > > > >>>>>>> critical path. Is that the primary motivation for creating
> the KIP?
> > > > >>>>>>>
> > > > >>>>>>> Thanks,
> > > > >>>>>>> Satish.
> > > > >>>>>>>
> > > > >>>>>>> On Wed, Jun 12, 2019 at 8:43 PM Andy Coates <
> andy@confluent.io>
> > > > >>>> wrote:
> > > > >>>>>>>
> > > > >>>>>>>> I'm not married to that part.  That was only done to keep
> it more
> > > > >>>> or
> > > > >>>>>> less
> > > > >>>>>>>> inline with what's already there, (an abstract class that
> has a
> > > > >>>>> factory
> > > > >>>>>>>> method that returns a subclass.... sounds like the same
> > > > >>>> anti-pattern
> > > > >>>>>> ;))
> > > > >>>>>>>>
> > > > >>>>>>>> An alternative would to have an `AdminClients` utility
> class to
> > > > >>>>> create
> > > > >>>>>>> the
> > > > >>>>>>>> admin client.
> > > > >>>>>>>>
> > > > >>>>>>>> On Mon, 10 Jun 2019 at 19:31, Matthias J. Sax <
> > > > >>>> matthias@confluent.io
> > > > >>>>>>
> > > > >>>>>>>> wrote:
> > > > >>>>>>>>
> > > > >>>>>>>>> Hmmm...
> > > > >>>>>>>>>
> > > > >>>>>>>>> So the new interface, returns an instance of a class that
> > > > >>>>> implements
> > > > >>>>>>> the
> > > > >>>>>>>>> interface. This sounds a little bit like an anti-pattern?
> > > > >>>> Shouldn't
> > > > >>>>>>>>> interfaces actually not know anything about classes that
> > > > >>>> implement
> > > > >>>>>> the
> > > > >>>>>>>>> interface?
> > > > >>>>>>>>>
> > > > >>>>>>>>>
> > > > >>>>>>>>> -Matthias
> > > > >>>>>>>>>
> > > > >>>>>>>>> On 6/10/19 11:22 AM, Andy Coates wrote:
> > > > >>>>>>>>>> `AdminClient` would be deprecated purely because it would
> no
> > > > >>>>> longer
> > > > >>>>>>>> serve
> > > > >>>>>>>>>> any purpose and would be virtually empty, getting all of
> its
> > > > >>>>>>>>> implementation
> > > > >>>>>>>>>> from the new interfar. It would be nice to remove this
> from the
> > > > >>>>> API
> > > > >>>>>>> at
> > > > >>>>>>>>> the
> > > > >>>>>>>>>> next major version bump, hence the need to deprecate.
> > > > >>>>>>>>>>
> > > > >>>>>>>>>> `AdminClient.create()` would return what it does today,
> (so
> > > > >>>> not a
> > > > >>>>>>>>> breaking
> > > > >>>>>>>>>> change).
> > > > >>>>>>>>>>
> > > > >>>>>>>>>> On Tue, 4 Jun 2019 at 22:24, Ryanne Dolan <
> > > > >>>> ryannedolan@gmail.com
> > > > >>>>>>
> > > > >>>>>>>> wrote:
> > > > >>>>>>>>>>
> > > > >>>>>>>>>>>> The existing `AdminClient` will be marked as deprecated.
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>>> What's the reasoning behind this? I'm fine with the other
> > > > >>>>> changes,
> > > > >>>>>>> but
> > > > >>>>>>>>>>> would prefer to keep the existing public API intact if
> it's
> > > > >>>> not
> > > > >>>>>>>> hurting
> > > > >>>>>>>>>>> anything.
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>>> Also, what will AdminClient.create() return? Would it be
> a
> > > > >>>>>> breaking
> > > > >>>>>>>>> change?
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>>> Ryanne
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>>> On Tue, Jun 4, 2019, 11:17 AM Andy Coates <
> andy@confluent.io>
> > > > >>>>>>> wrote:
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>>>> Hi folks
> > > > >>>>>>>>>>>>
> > > > >>>>>>>>>>>> As there's been no chatter on this KIP I'm assuming it's
> > > > >>>>>>>>> non-contentious,
> > > > >>>>>>>>>>>> (or just boring), hence I'd like to call a vote for
> KIP-476:
> > > > >>>>>>>>>>>>
> > > > >>>>>>>>>>>>
> > > > >>>>>>>>>>>>
> > > > >>>>>>>>>
> > > > >>>>>>>>
> > > > >>>>>>>
> > > > >>>>>>
> > > > >>>>>
> > > > >>>>
> > > > >>
> > > >
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-476%3A+Add+Java+AdminClient+Interface
> > > > >>>>>>>>>>>>
> > > > >>>>>>>>>>>> Thanks,
> > > > >>>>>>>>>>>>
> > > > >>>>>>>>>>>> Andy
> > > > >>>>>>>>>>>>
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>>
> > > > >>>>>>>>>
> > > > >>>>>>>>>
> > > > >>>>>>>>
> > > > >>>>>>>
> > > > >>>>>>
> > > > >>>>>
> > > > >>>>
> > > > >>
> > > > >>
> > > > >
> > > >
> > > >
>

Re: [VOTE] KIP-476: Add Java AdminClient interface

Posted by Satish Duggana <sa...@gmail.com>.

+1 (non-binding)

On Wed, Jun 26, 2019 at 8:37 AM Satish Duggana <sa...@gmail.com> wrote:
>
> +1 Matthias/Andy.
> IMHO, interface is about the contract, it should not have/expose any
> implementation. I am fine with either way as it is more of taste or
> preference.
>
> Agree with Ismael/Colin/Ryanne on not deprecating for good reasons.
>
>
> On Mon, Jun 24, 2019 at 8:33 PM Andy Coates <an...@confluent.io> wrote:
> >
> > I agree Matthias.
> >
> > (In Scala, such factory methods are on a companion object. As Java doesn't
> > have the concept of a companion object, an equivalent would be a utility
> > class with a similar name...)
> >
> > However, I'll update the KIP to include the factory method on the interface.
> >
> > On Fri, 21 Jun 2019 at 23:40, Matthias J. Sax <ma...@confluent.io> wrote:
> >
> > > I still think, that an interface does not need to know anything about
> > > its implementation. But I am also fine if we add a factory method to the
> > > new interface if that is preferred by most people.
> > >
> > >
> > > -Matthias
> > >
> > > On 6/21/19 7:10 AM, Ismael Juma wrote:
> > > > This is even more reason not to deprecate immediately, there is very
> > > little
> > > > maintenance cost for us. We should be mindful that many of our users (eg
> > > > Spark, Flink, etc.) typically allow users to specify the kafka clients
> > > > version and hence avoid using new classes/interfaces for some time. They
> > > > would get a bunch of warnings they cannot do anything about apart from
> > > > suppressing.
> > > >
> > > > Ismael
> > > >
> > > > On Fri, Jun 21, 2019 at 4:00 AM Andy Coates <an...@confluent.io> wrote:
> > > >
> > > >> Hi Ismael,
> > > >>
> > > >> I’m happy enough to not deprecate the existing `AdminClient` class as
> > > part
> > > >> of this change.
> > > >>
> > > >> However, note that, the class will likely be empty, i.e. all methods and
> > > >> implementations will be inherited from the interface:
> > > >>
> > > >> public abstract class AdminClient implements Admin {
> > > >> }
> > > >>
> > > >> Not marking it as deprecated has the benefit that users won’t see any
> > > >> deprecation warnings on the next release. Conversely, deprecating it
> > > will
> > > >> mean we can choose to remove this, now pointless class, in the future
> > > if we
> > > >> choose.
> > > >>
> > > >> That’s my thinking for deprecation, but as I’ve said I’m happy either
> > > way.
> > > >>
> > > >> Andy
> > > >>
> > > >>> On 18 Jun 2019, at 16:09, Ismael Juma <is...@juma.me.uk> wrote:
> > > >>>
> > > >>> I agree with Ryanne, I think we should avoid deprecating AdminClient
> > > and
> > > >>> causing so much churn for users who don't actually care about this
> > > niche
> > > >>> use case.
> > > >>>
> > > >>> Ismael
> > > >>>
> > > >>> On Tue, Jun 18, 2019 at 6:43 AM Andy Coates <an...@confluent.io> wrote:
> > > >>>
> > > >>>> Hi Ryanne,
> > > >>>>
> > > >>>> If we don't change the client code, then everywhere will still expect
> > > >>>> subclasses of `AdminClient`, so the interface will be of no use, i.e.
> > > I
> > > >>>> can't write a class that implements the new interface and pass it to
> > > the
> > > >>>> client code.
> > > >>>>
> > > >>>> Thanks,
> > > >>>>
> > > >>>> Andy
> > > >>>>
> > > >>>> On Mon, 17 Jun 2019 at 19:01, Ryanne Dolan <ry...@gmail.com>
> > > >> wrote:
> > > >>>>
> > > >>>>> Andy, while I agree that the new interface is useful, I'm not
> > > convinced
> > > >>>>> adding an interface requires deprecating AdminClient and changing so
> > > >> much
> > > >>>>> client code. Why not just add the Admin interface, have AdminClient
> > > >>>>> implement it, and have done?
> > > >>>>>
> > > >>>>> Ryanne
> > > >>>>>
> > > >>>>> On Mon, Jun 17, 2019 at 12:09 PM Andy Coates <an...@confluent.io>
> > > >> wrote:
> > > >>>>>
> > > >>>>>> Hi all,
> > > >>>>>>
> > > >>>>>> I think I've addressed all concerns. Let me know if I've not.  Can I
> > > >>>> call
> > > >>>>>> another round of votes please?
> > > >>>>>>
> > > >>>>>> Thanks,
> > > >>>>>>
> > > >>>>>> Andy
> > > >>>>>>
> > > >>>>>> On Fri, 14 Jun 2019 at 04:55, Satish Duggana <
> > > >> satish.duggana@gmail.com
> > > >>>>>
> > > >>>>>> wrote:
> > > >>>>>>
> > > >>>>>>> Hi Andy,
> > > >>>>>>> Thanks for the KIP. This is a good change and it gives the user a
> > > >>>>> better
> > > >>>>>>> handle on Admin client usage. I agree with the proposal except the
> > > >>>> new
> > > >>>>>>> `Admin` interface having all the methods from `AdminClient`
> > > abstract
> > > >>>>>> class.
> > > >>>>>>> It should be kept clean having only the admin operations as methods
> > > >>>>> from
> > > >>>>>>> KafkaClient abstract class but not the factory methods as mentioned
> > > >>>> in
> > > >>>>>> the
> > > >>>>>>> earlier mail.
> > > >>>>>>>
> > > >>>>>>> I know about dynamic proxies(which were widely used in RMI/EJB
> > > >>>> world).
> > > >>>>> I
> > > >>>>>> am
> > > >>>>>>> curious about the usecase using dynamic proxies with Admin client
> > > >>>>>>> interface. Dynamic proxy can have performance penalty if it is used
> > > >>>> in
> > > >>>>>>> critical path. Is that the primary motivation for creating the KIP?
> > > >>>>>>>
> > > >>>>>>> Thanks,
> > > >>>>>>> Satish.
> > > >>>>>>>
> > > >>>>>>> On Wed, Jun 12, 2019 at 8:43 PM Andy Coates <an...@confluent.io>
> > > >>>> wrote:
> > > >>>>>>>
> > > >>>>>>>> I'm not married to that part.  That was only done to keep it more
> > > >>>> or
> > > >>>>>> less
> > > >>>>>>>> inline with what's already there, (an abstract class that has a
> > > >>>>> factory
> > > >>>>>>>> method that returns a subclass.... sounds like the same
> > > >>>> anti-pattern
> > > >>>>>> ;))
> > > >>>>>>>>
> > > >>>>>>>> An alternative would to have an `AdminClients` utility class to
> > > >>>>> create
> > > >>>>>>> the
> > > >>>>>>>> admin client.
> > > >>>>>>>>
> > > >>>>>>>> On Mon, 10 Jun 2019 at 19:31, Matthias J. Sax <
> > > >>>> matthias@confluent.io
> > > >>>>>>
> > > >>>>>>>> wrote:
> > > >>>>>>>>
> > > >>>>>>>>> Hmmm...
> > > >>>>>>>>>
> > > >>>>>>>>> So the new interface, returns an instance of a class that
> > > >>>>> implements
> > > >>>>>>> the
> > > >>>>>>>>> interface. This sounds a little bit like an anti-pattern?
> > > >>>> Shouldn't
> > > >>>>>>>>> interfaces actually not know anything about classes that
> > > >>>> implement
> > > >>>>>> the
> > > >>>>>>>>> interface?
> > > >>>>>>>>>
> > > >>>>>>>>>
> > > >>>>>>>>> -Matthias
> > > >>>>>>>>>
> > > >>>>>>>>> On 6/10/19 11:22 AM, Andy Coates wrote:
> > > >>>>>>>>>> `AdminClient` would be deprecated purely because it would no
> > > >>>>> longer
> > > >>>>>>>> serve
> > > >>>>>>>>>> any purpose and would be virtually empty, getting all of its
> > > >>>>>>>>> implementation
> > > >>>>>>>>>> from the new interfar. It would be nice to remove this from the
> > > >>>>> API
> > > >>>>>>> at
> > > >>>>>>>>> the
> > > >>>>>>>>>> next major version bump, hence the need to deprecate.
> > > >>>>>>>>>>
> > > >>>>>>>>>> `AdminClient.create()` would return what it does today, (so
> > > >>>> not a
> > > >>>>>>>>> breaking
> > > >>>>>>>>>> change).
> > > >>>>>>>>>>
> > > >>>>>>>>>> On Tue, 4 Jun 2019 at 22:24, Ryanne Dolan <
> > > >>>> ryannedolan@gmail.com
> > > >>>>>>
> > > >>>>>>>> wrote:
> > > >>>>>>>>>>
> > > >>>>>>>>>>>> The existing `AdminClient` will be marked as deprecated.
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> What's the reasoning behind this? I'm fine with the other
> > > >>>>> changes,
> > > >>>>>>> but
> > > >>>>>>>>>>> would prefer to keep the existing public API intact if it's
> > > >>>> not
> > > >>>>>>>> hurting
> > > >>>>>>>>>>> anything.
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> Also, what will AdminClient.create() return? Would it be a
> > > >>>>>> breaking
> > > >>>>>>>>> change?
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> Ryanne
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> On Tue, Jun 4, 2019, 11:17 AM Andy Coates <an...@confluent.io>
> > > >>>>>>> wrote:
> > > >>>>>>>>>>>
> > > >>>>>>>>>>>> Hi folks
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> As there's been no chatter on this KIP I'm assuming it's
> > > >>>>>>>>> non-contentious,
> > > >>>>>>>>>>>> (or just boring), hence I'd like to call a vote for KIP-476:
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>>
> > > >>>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>
> > > >>>>>>
> > > >>>>>
> > > >>>>
> > > >>
> > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-476%3A+Add+Java+AdminClient+Interface
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> Thanks,
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> Andy
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>
> > > >>>>>>>>>>
> > > >>>>>>>>>
> > > >>>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>
> > > >>>>>>
> > > >>>>>
> > > >>>>
> > > >>
> > > >>
> > > >
> > >
> > >

Re: [VOTE] KIP-476: Add Java AdminClient interface

Posted by Satish Duggana <sa...@gmail.com>.

+1 Matthias/Andy.
IMHO, interface is about the contract, it should not have/expose any
implementation. I am fine with either way as it is more of taste or
preference.

Agree with Ismael/Colin/Ryanne on not deprecating for good reasons.


On Mon, Jun 24, 2019 at 8:33 PM Andy Coates <an...@confluent.io> wrote:
>
> I agree Matthias.
>
> (In Scala, such factory methods are on a companion object. As Java doesn't
> have the concept of a companion object, an equivalent would be a utility
> class with a similar name...)
>
> However, I'll update the KIP to include the factory method on the interface.
>
> On Fri, 21 Jun 2019 at 23:40, Matthias J. Sax <ma...@confluent.io> wrote:
>
> > I still think, that an interface does not need to know anything about
> > its implementation. But I am also fine if we add a factory method to the
> > new interface if that is preferred by most people.
> >
> >
> > -Matthias
> >
> > On 6/21/19 7:10 AM, Ismael Juma wrote:
> > > This is even more reason not to deprecate immediately, there is very
> > little
> > > maintenance cost for us. We should be mindful that many of our users (eg
> > > Spark, Flink, etc.) typically allow users to specify the kafka clients
> > > version and hence avoid using new classes/interfaces for some time. They
> > > would get a bunch of warnings they cannot do anything about apart from
> > > suppressing.
> > >
> > > Ismael
> > >
> > > On Fri, Jun 21, 2019 at 4:00 AM Andy Coates <an...@confluent.io> wrote:
> > >
> > >> Hi Ismael,
> > >>
> > >> I’m happy enough to not deprecate the existing `AdminClient` class as
> > part
> > >> of this change.
> > >>
> > >> However, note that, the class will likely be empty, i.e. all methods and
> > >> implementations will be inherited from the interface:
> > >>
> > >> public abstract class AdminClient implements Admin {
> > >> }
> > >>
> > >> Not marking it as deprecated has the benefit that users won’t see any
> > >> deprecation warnings on the next release. Conversely, deprecating it
> > will
> > >> mean we can choose to remove this, now pointless class, in the future
> > if we
> > >> choose.
> > >>
> > >> That’s my thinking for deprecation, but as I’ve said I’m happy either
> > way.
> > >>
> > >> Andy
> > >>
> > >>> On 18 Jun 2019, at 16:09, Ismael Juma <is...@juma.me.uk> wrote:
> > >>>
> > >>> I agree with Ryanne, I think we should avoid deprecating AdminClient
> > and
> > >>> causing so much churn for users who don't actually care about this
> > niche
> > >>> use case.
> > >>>
> > >>> Ismael
> > >>>
> > >>> On Tue, Jun 18, 2019 at 6:43 AM Andy Coates <an...@confluent.io> wrote:
> > >>>
> > >>>> Hi Ryanne,
> > >>>>
> > >>>> If we don't change the client code, then everywhere will still expect
> > >>>> subclasses of `AdminClient`, so the interface will be of no use, i.e.
> > I
> > >>>> can't write a class that implements the new interface and pass it to
> > the
> > >>>> client code.
> > >>>>
> > >>>> Thanks,
> > >>>>
> > >>>> Andy
> > >>>>
> > >>>> On Mon, 17 Jun 2019 at 19:01, Ryanne Dolan <ry...@gmail.com>
> > >> wrote:
> > >>>>
> > >>>>> Andy, while I agree that the new interface is useful, I'm not
> > convinced
> > >>>>> adding an interface requires deprecating AdminClient and changing so
> > >> much
> > >>>>> client code. Why not just add the Admin interface, have AdminClient
> > >>>>> implement it, and have done?
> > >>>>>
> > >>>>> Ryanne
> > >>>>>
> > >>>>> On Mon, Jun 17, 2019 at 12:09 PM Andy Coates <an...@confluent.io>
> > >> wrote:
> > >>>>>
> > >>>>>> Hi all,
> > >>>>>>
> > >>>>>> I think I've addressed all concerns. Let me know if I've not.  Can I
> > >>>> call
> > >>>>>> another round of votes please?
> > >>>>>>
> > >>>>>> Thanks,
> > >>>>>>
> > >>>>>> Andy
> > >>>>>>
> > >>>>>> On Fri, 14 Jun 2019 at 04:55, Satish Duggana <
> > >> satish.duggana@gmail.com
> > >>>>>
> > >>>>>> wrote:
> > >>>>>>
> > >>>>>>> Hi Andy,
> > >>>>>>> Thanks for the KIP. This is a good change and it gives the user a
> > >>>>> better
> > >>>>>>> handle on Admin client usage. I agree with the proposal except the
> > >>>> new
> > >>>>>>> `Admin` interface having all the methods from `AdminClient`
> > abstract
> > >>>>>> class.
> > >>>>>>> It should be kept clean having only the admin operations as methods
> > >>>>> from
> > >>>>>>> KafkaClient abstract class but not the factory methods as mentioned
> > >>>> in
> > >>>>>> the
> > >>>>>>> earlier mail.
> > >>>>>>>
> > >>>>>>> I know about dynamic proxies(which were widely used in RMI/EJB
> > >>>> world).
> > >>>>> I
> > >>>>>> am
> > >>>>>>> curious about the usecase using dynamic proxies with Admin client
> > >>>>>>> interface. Dynamic proxy can have performance penalty if it is used
> > >>>> in
> > >>>>>>> critical path. Is that the primary motivation for creating the KIP?
> > >>>>>>>
> > >>>>>>> Thanks,
> > >>>>>>> Satish.
> > >>>>>>>
> > >>>>>>> On Wed, Jun 12, 2019 at 8:43 PM Andy Coates <an...@confluent.io>
> > >>>> wrote:
> > >>>>>>>
> > >>>>>>>> I'm not married to that part.  That was only done to keep it more
> > >>>> or
> > >>>>>> less
> > >>>>>>>> inline with what's already there, (an abstract class that has a
> > >>>>> factory
> > >>>>>>>> method that returns a subclass.... sounds like the same
> > >>>> anti-pattern
> > >>>>>> ;))
> > >>>>>>>>
> > >>>>>>>> An alternative would to have an `AdminClients` utility class to
> > >>>>> create
> > >>>>>>> the
> > >>>>>>>> admin client.
> > >>>>>>>>
> > >>>>>>>> On Mon, 10 Jun 2019 at 19:31, Matthias J. Sax <
> > >>>> matthias@confluent.io
> > >>>>>>
> > >>>>>>>> wrote:
> > >>>>>>>>
> > >>>>>>>>> Hmmm...
> > >>>>>>>>>
> > >>>>>>>>> So the new interface, returns an instance of a class that
> > >>>>> implements
> > >>>>>>> the
> > >>>>>>>>> interface. This sounds a little bit like an anti-pattern?
> > >>>> Shouldn't
> > >>>>>>>>> interfaces actually not know anything about classes that
> > >>>> implement
> > >>>>>> the
> > >>>>>>>>> interface?
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>> -Matthias
> > >>>>>>>>>
> > >>>>>>>>> On 6/10/19 11:22 AM, Andy Coates wrote:
> > >>>>>>>>>> `AdminClient` would be deprecated purely because it would no
> > >>>>> longer
> > >>>>>>>> serve
> > >>>>>>>>>> any purpose and would be virtually empty, getting all of its
> > >>>>>>>>> implementation
> > >>>>>>>>>> from the new interfar. It would be nice to remove this from the
> > >>>>> API
> > >>>>>>> at
> > >>>>>>>>> the
> > >>>>>>>>>> next major version bump, hence the need to deprecate.
> > >>>>>>>>>>
> > >>>>>>>>>> `AdminClient.create()` would return what it does today, (so
> > >>>> not a
> > >>>>>>>>> breaking
> > >>>>>>>>>> change).
> > >>>>>>>>>>
> > >>>>>>>>>> On Tue, 4 Jun 2019 at 22:24, Ryanne Dolan <
> > >>>> ryannedolan@gmail.com
> > >>>>>>
> > >>>>>>>> wrote:
> > >>>>>>>>>>
> > >>>>>>>>>>>> The existing `AdminClient` will be marked as deprecated.
> > >>>>>>>>>>>
> > >>>>>>>>>>> What's the reasoning behind this? I'm fine with the other
> > >>>>> changes,
> > >>>>>>> but
> > >>>>>>>>>>> would prefer to keep the existing public API intact if it's
> > >>>> not
> > >>>>>>>> hurting
> > >>>>>>>>>>> anything.
> > >>>>>>>>>>>
> > >>>>>>>>>>> Also, what will AdminClient.create() return? Would it be a
> > >>>>>> breaking
> > >>>>>>>>> change?
> > >>>>>>>>>>>
> > >>>>>>>>>>> Ryanne
> > >>>>>>>>>>>
> > >>>>>>>>>>> On Tue, Jun 4, 2019, 11:17 AM Andy Coates <an...@confluent.io>
> > >>>>>>> wrote:
> > >>>>>>>>>>>
> > >>>>>>>>>>>> Hi folks
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> As there's been no chatter on this KIP I'm assuming it's
> > >>>>>>>>> non-contentious,
> > >>>>>>>>>>>> (or just boring), hence I'd like to call a vote for KIP-476:
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>
> > >>>>>>>
> > >>>>>>
> > >>>>>
> > >>>>
> > >>
> > https://cwiki.apache.org/confluence/display/KAFKA/KIP-476%3A+Add+Java+AdminClient+Interface
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> Thanks,
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> Andy
> > >>>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>
> > >>>>>>>
> > >>>>>>
> > >>>>>
> > >>>>
> > >>
> > >>
> > >
> >
> >

Re: [VOTE] KIP-476: Add Java AdminClient interface

Posted by Andy Coates <an...@confluent.io>.

I agree Matthias.

(In Scala, such factory methods are on a companion object. As Java doesn't
have the concept of a companion object, an equivalent would be a utility
class with a similar name...)

However, I'll update the KIP to include the factory method on the interface.

On Fri, 21 Jun 2019 at 23:40, Matthias J. Sax <ma...@confluent.io> wrote:

> I still think, that an interface does not need to know anything about
> its implementation. But I am also fine if we add a factory method to the
> new interface if that is preferred by most people.
>
>
> -Matthias
>
> On 6/21/19 7:10 AM, Ismael Juma wrote:
> > This is even more reason not to deprecate immediately, there is very
> little
> > maintenance cost for us. We should be mindful that many of our users (eg
> > Spark, Flink, etc.) typically allow users to specify the kafka clients
> > version and hence avoid using new classes/interfaces for some time. They
> > would get a bunch of warnings they cannot do anything about apart from
> > suppressing.
> >
> > Ismael
> >
> > On Fri, Jun 21, 2019 at 4:00 AM Andy Coates <an...@confluent.io> wrote:
> >
> >> Hi Ismael,
> >>
> >> I’m happy enough to not deprecate the existing `AdminClient` class as
> part
> >> of this change.
> >>
> >> However, note that, the class will likely be empty, i.e. all methods and
> >> implementations will be inherited from the interface:
> >>
> >> public abstract class AdminClient implements Admin {
> >> }
> >>
> >> Not marking it as deprecated has the benefit that users won’t see any
> >> deprecation warnings on the next release. Conversely, deprecating it
> will
> >> mean we can choose to remove this, now pointless class, in the future
> if we
> >> choose.
> >>
> >> That’s my thinking for deprecation, but as I’ve said I’m happy either
> way.
> >>
> >> Andy
> >>
> >>> On 18 Jun 2019, at 16:09, Ismael Juma <is...@juma.me.uk> wrote:
> >>>
> >>> I agree with Ryanne, I think we should avoid deprecating AdminClient
> and
> >>> causing so much churn for users who don't actually care about this
> niche
> >>> use case.
> >>>
> >>> Ismael
> >>>
> >>> On Tue, Jun 18, 2019 at 6:43 AM Andy Coates <an...@confluent.io> wrote:
> >>>
> >>>> Hi Ryanne,
> >>>>
> >>>> If we don't change the client code, then everywhere will still expect
> >>>> subclasses of `AdminClient`, so the interface will be of no use, i.e.
> I
> >>>> can't write a class that implements the new interface and pass it to
> the
> >>>> client code.
> >>>>
> >>>> Thanks,
> >>>>
> >>>> Andy
> >>>>
> >>>> On Mon, 17 Jun 2019 at 19:01, Ryanne Dolan <ry...@gmail.com>
> >> wrote:
> >>>>
> >>>>> Andy, while I agree that the new interface is useful, I'm not
> convinced
> >>>>> adding an interface requires deprecating AdminClient and changing so
> >> much
> >>>>> client code. Why not just add the Admin interface, have AdminClient
> >>>>> implement it, and have done?
> >>>>>
> >>>>> Ryanne
> >>>>>
> >>>>> On Mon, Jun 17, 2019 at 12:09 PM Andy Coates <an...@confluent.io>
> >> wrote:
> >>>>>
> >>>>>> Hi all,
> >>>>>>
> >>>>>> I think I've addressed all concerns. Let me know if I've not.  Can I
> >>>> call
> >>>>>> another round of votes please?
> >>>>>>
> >>>>>> Thanks,
> >>>>>>
> >>>>>> Andy
> >>>>>>
> >>>>>> On Fri, 14 Jun 2019 at 04:55, Satish Duggana <
> >> satish.duggana@gmail.com
> >>>>>
> >>>>>> wrote:
> >>>>>>
> >>>>>>> Hi Andy,
> >>>>>>> Thanks for the KIP. This is a good change and it gives the user a
> >>>>> better
> >>>>>>> handle on Admin client usage. I agree with the proposal except the
> >>>> new
> >>>>>>> `Admin` interface having all the methods from `AdminClient`
> abstract
> >>>>>> class.
> >>>>>>> It should be kept clean having only the admin operations as methods
> >>>>> from
> >>>>>>> KafkaClient abstract class but not the factory methods as mentioned
> >>>> in
> >>>>>> the
> >>>>>>> earlier mail.
> >>>>>>>
> >>>>>>> I know about dynamic proxies(which were widely used in RMI/EJB
> >>>> world).
> >>>>> I
> >>>>>> am
> >>>>>>> curious about the usecase using dynamic proxies with Admin client
> >>>>>>> interface. Dynamic proxy can have performance penalty if it is used
> >>>> in
> >>>>>>> critical path. Is that the primary motivation for creating the KIP?
> >>>>>>>
> >>>>>>> Thanks,
> >>>>>>> Satish.
> >>>>>>>
> >>>>>>> On Wed, Jun 12, 2019 at 8:43 PM Andy Coates <an...@confluent.io>
> >>>> wrote:
> >>>>>>>
> >>>>>>>> I'm not married to that part.  That was only done to keep it more
> >>>> or
> >>>>>> less
> >>>>>>>> inline with what's already there, (an abstract class that has a
> >>>>> factory
> >>>>>>>> method that returns a subclass.... sounds like the same
> >>>> anti-pattern
> >>>>>> ;))
> >>>>>>>>
> >>>>>>>> An alternative would to have an `AdminClients` utility class to
> >>>>> create
> >>>>>>> the
> >>>>>>>> admin client.
> >>>>>>>>
> >>>>>>>> On Mon, 10 Jun 2019 at 19:31, Matthias J. Sax <
> >>>> matthias@confluent.io
> >>>>>>
> >>>>>>>> wrote:
> >>>>>>>>
> >>>>>>>>> Hmmm...
> >>>>>>>>>
> >>>>>>>>> So the new interface, returns an instance of a class that
> >>>>> implements
> >>>>>>> the
> >>>>>>>>> interface. This sounds a little bit like an anti-pattern?
> >>>> Shouldn't
> >>>>>>>>> interfaces actually not know anything about classes that
> >>>> implement
> >>>>>> the
> >>>>>>>>> interface?
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> -Matthias
> >>>>>>>>>
> >>>>>>>>> On 6/10/19 11:22 AM, Andy Coates wrote:
> >>>>>>>>>> `AdminClient` would be deprecated purely because it would no
> >>>>> longer
> >>>>>>>> serve
> >>>>>>>>>> any purpose and would be virtually empty, getting all of its
> >>>>>>>>> implementation
> >>>>>>>>>> from the new interfar. It would be nice to remove this from the
> >>>>> API
> >>>>>>> at
> >>>>>>>>> the
> >>>>>>>>>> next major version bump, hence the need to deprecate.
> >>>>>>>>>>
> >>>>>>>>>> `AdminClient.create()` would return what it does today, (so
> >>>> not a
> >>>>>>>>> breaking
> >>>>>>>>>> change).
> >>>>>>>>>>
> >>>>>>>>>> On Tue, 4 Jun 2019 at 22:24, Ryanne Dolan <
> >>>> ryannedolan@gmail.com
> >>>>>>
> >>>>>>>> wrote:
> >>>>>>>>>>
> >>>>>>>>>>>> The existing `AdminClient` will be marked as deprecated.
> >>>>>>>>>>>
> >>>>>>>>>>> What's the reasoning behind this? I'm fine with the other
> >>>>> changes,
> >>>>>>> but
> >>>>>>>>>>> would prefer to keep the existing public API intact if it's
> >>>> not
> >>>>>>>> hurting
> >>>>>>>>>>> anything.
> >>>>>>>>>>>
> >>>>>>>>>>> Also, what will AdminClient.create() return? Would it be a
> >>>>>> breaking
> >>>>>>>>> change?
> >>>>>>>>>>>
> >>>>>>>>>>> Ryanne
> >>>>>>>>>>>
> >>>>>>>>>>> On Tue, Jun 4, 2019, 11:17 AM Andy Coates <an...@confluent.io>
> >>>>>>> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>>> Hi folks
> >>>>>>>>>>>>
> >>>>>>>>>>>> As there's been no chatter on this KIP I'm assuming it's
> >>>>>>>>> non-contentious,
> >>>>>>>>>>>> (or just boring), hence I'd like to call a vote for KIP-476:
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-476%3A+Add+Java+AdminClient+Interface
> >>>>>>>>>>>>
> >>>>>>>>>>>> Thanks,
> >>>>>>>>>>>>
> >>>>>>>>>>>> Andy
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>
> >>
> >
>
>

Re: [VOTE] KIP-476: Add Java AdminClient interface

Posted by Colin McCabe <cm...@apache.org>.

Just to give a little context here, the main reason for having the AdminClient#create method is so that end-users didn't have to import KafkaAdminClient.  In general, users should be interacting with the AdminClient API, not with the implementation class(es).

Also, I have to grudgingly agree that marking the old AdminClient as deprecated will be a huge pain.  Especially in Scala, where we (currently, at least) have no way to suppress deprecation warnings.  So maybe we should not do that, just yet.

best,
Colin


On Fri, Jun 21, 2019, at 15:41, Matthias J. Sax wrote:
> I still think, that an interface does not need to know anything about
> its implementation. But I am also fine if we add a factory method to the
> new interface if that is preferred by most people.
> 
> 
> -Matthias
> 
> On 6/21/19 7:10 AM, Ismael Juma wrote:
> > This is even more reason not to deprecate immediately, there is very little
> > maintenance cost for us. We should be mindful that many of our users (eg
> > Spark, Flink, etc.) typically allow users to specify the kafka clients
> > version and hence avoid using new classes/interfaces for some time. They
> > would get a bunch of warnings they cannot do anything about apart from
> > suppressing.
> > 
> > Ismael
> > 
> > On Fri, Jun 21, 2019 at 4:00 AM Andy Coates <an...@confluent.io> wrote:
> > 
> >> Hi Ismael,
> >>
> >> I’m happy enough to not deprecate the existing `AdminClient` class as part
> >> of this change.
> >>
> >> However, note that, the class will likely be empty, i.e. all methods and
> >> implementations will be inherited from the interface:
> >>
> >> public abstract class AdminClient implements Admin {
> >> }
> >>
> >> Not marking it as deprecated has the benefit that users won’t see any
> >> deprecation warnings on the next release. Conversely, deprecating it will
> >> mean we can choose to remove this, now pointless class, in the future if we
> >> choose.
> >>
> >> That’s my thinking for deprecation, but as I’ve said I’m happy either way.
> >>
> >> Andy
> >>
> >>> On 18 Jun 2019, at 16:09, Ismael Juma <is...@juma.me.uk> wrote:
> >>>
> >>> I agree with Ryanne, I think we should avoid deprecating AdminClient and
> >>> causing so much churn for users who don't actually care about this niche
> >>> use case.
> >>>
> >>> Ismael
> >>>
> >>> On Tue, Jun 18, 2019 at 6:43 AM Andy Coates <an...@confluent.io> wrote:
> >>>
> >>>> Hi Ryanne,
> >>>>
> >>>> If we don't change the client code, then everywhere will still expect
> >>>> subclasses of `AdminClient`, so the interface will be of no use, i.e. I
> >>>> can't write a class that implements the new interface and pass it to the
> >>>> client code.
> >>>>
> >>>> Thanks,
> >>>>
> >>>> Andy
> >>>>
> >>>> On Mon, 17 Jun 2019 at 19:01, Ryanne Dolan <ry...@gmail.com>
> >> wrote:
> >>>>
> >>>>> Andy, while I agree that the new interface is useful, I'm not convinced
> >>>>> adding an interface requires deprecating AdminClient and changing so
> >> much
> >>>>> client code. Why not just add the Admin interface, have AdminClient
> >>>>> implement it, and have done?
> >>>>>
> >>>>> Ryanne
> >>>>>
> >>>>> On Mon, Jun 17, 2019 at 12:09 PM Andy Coates <an...@confluent.io>
> >> wrote:
> >>>>>
> >>>>>> Hi all,
> >>>>>>
> >>>>>> I think I've addressed all concerns. Let me know if I've not.  Can I
> >>>> call
> >>>>>> another round of votes please?
> >>>>>>
> >>>>>> Thanks,
> >>>>>>
> >>>>>> Andy
> >>>>>>
> >>>>>> On Fri, 14 Jun 2019 at 04:55, Satish Duggana <
> >> satish.duggana@gmail.com
> >>>>>
> >>>>>> wrote:
> >>>>>>
> >>>>>>> Hi Andy,
> >>>>>>> Thanks for the KIP. This is a good change and it gives the user a
> >>>>> better
> >>>>>>> handle on Admin client usage. I agree with the proposal except the
> >>>> new
> >>>>>>> `Admin` interface having all the methods from `AdminClient` abstract
> >>>>>> class.
> >>>>>>> It should be kept clean having only the admin operations as methods
> >>>>> from
> >>>>>>> KafkaClient abstract class but not the factory methods as mentioned
> >>>> in
> >>>>>> the
> >>>>>>> earlier mail.
> >>>>>>>
> >>>>>>> I know about dynamic proxies(which were widely used in RMI/EJB
> >>>> world).
> >>>>> I
> >>>>>> am
> >>>>>>> curious about the usecase using dynamic proxies with Admin client
> >>>>>>> interface. Dynamic proxy can have performance penalty if it is used
> >>>> in
> >>>>>>> critical path. Is that the primary motivation for creating the KIP?
> >>>>>>>
> >>>>>>> Thanks,
> >>>>>>> Satish.
> >>>>>>>
> >>>>>>> On Wed, Jun 12, 2019 at 8:43 PM Andy Coates <an...@confluent.io>
> >>>> wrote:
> >>>>>>>
> >>>>>>>> I'm not married to that part.  That was only done to keep it more
> >>>> or
> >>>>>> less
> >>>>>>>> inline with what's already there, (an abstract class that has a
> >>>>> factory
> >>>>>>>> method that returns a subclass.... sounds like the same
> >>>> anti-pattern
> >>>>>> ;))
> >>>>>>>>
> >>>>>>>> An alternative would to have an `AdminClients` utility class to
> >>>>> create
> >>>>>>> the
> >>>>>>>> admin client.
> >>>>>>>>
> >>>>>>>> On Mon, 10 Jun 2019 at 19:31, Matthias J. Sax <
> >>>> matthias@confluent.io
> >>>>>>
> >>>>>>>> wrote:
> >>>>>>>>
> >>>>>>>>> Hmmm...
> >>>>>>>>>
> >>>>>>>>> So the new interface, returns an instance of a class that
> >>>>> implements
> >>>>>>> the
> >>>>>>>>> interface. This sounds a little bit like an anti-pattern?
> >>>> Shouldn't
> >>>>>>>>> interfaces actually not know anything about classes that
> >>>> implement
> >>>>>> the
> >>>>>>>>> interface?
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> -Matthias
> >>>>>>>>>
> >>>>>>>>> On 6/10/19 11:22 AM, Andy Coates wrote:
> >>>>>>>>>> `AdminClient` would be deprecated purely because it would no
> >>>>> longer
> >>>>>>>> serve
> >>>>>>>>>> any purpose and would be virtually empty, getting all of its
> >>>>>>>>> implementation
> >>>>>>>>>> from the new interfar. It would be nice to remove this from the
> >>>>> API
> >>>>>>> at
> >>>>>>>>> the
> >>>>>>>>>> next major version bump, hence the need to deprecate.
> >>>>>>>>>>
> >>>>>>>>>> `AdminClient.create()` would return what it does today, (so
> >>>> not a
> >>>>>>>>> breaking
> >>>>>>>>>> change).
> >>>>>>>>>>
> >>>>>>>>>> On Tue, 4 Jun 2019 at 22:24, Ryanne Dolan <
> >>>> ryannedolan@gmail.com
> >>>>>>
> >>>>>>>> wrote:
> >>>>>>>>>>
> >>>>>>>>>>>> The existing `AdminClient` will be marked as deprecated.
> >>>>>>>>>>>
> >>>>>>>>>>> What's the reasoning behind this? I'm fine with the other
> >>>>> changes,
> >>>>>>> but
> >>>>>>>>>>> would prefer to keep the existing public API intact if it's
> >>>> not
> >>>>>>>> hurting
> >>>>>>>>>>> anything.
> >>>>>>>>>>>
> >>>>>>>>>>> Also, what will AdminClient.create() return? Would it be a
> >>>>>> breaking
> >>>>>>>>> change?
> >>>>>>>>>>>
> >>>>>>>>>>> Ryanne
> >>>>>>>>>>>
> >>>>>>>>>>> On Tue, Jun 4, 2019, 11:17 AM Andy Coates <an...@confluent.io>
> >>>>>>> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>>> Hi folks
> >>>>>>>>>>>>
> >>>>>>>>>>>> As there's been no chatter on this KIP I'm assuming it's
> >>>>>>>>> non-contentious,
> >>>>>>>>>>>> (or just boring), hence I'd like to call a vote for KIP-476:
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>
> >> https://cwiki.apache.org/confluence/display/KAFKA/KIP-476%3A+Add+Java+AdminClient+Interface
> >>>>>>>>>>>>
> >>>>>>>>>>>> Thanks,
> >>>>>>>>>>>>
> >>>>>>>>>>>> Andy
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>
> >>
> > 
> 
> 
> Attachments:
> * signature.asc

Re: [VOTE] KIP-476: Add Java AdminClient interface

Posted by "Matthias J. Sax" <ma...@confluent.io>.

I still think, that an interface does not need to know anything about
its implementation. But I am also fine if we add a factory method to the
new interface if that is preferred by most people.


-Matthias

On 6/21/19 7:10 AM, Ismael Juma wrote:
> This is even more reason not to deprecate immediately, there is very little
> maintenance cost for us. We should be mindful that many of our users (eg
> Spark, Flink, etc.) typically allow users to specify the kafka clients
> version and hence avoid using new classes/interfaces for some time. They
> would get a bunch of warnings they cannot do anything about apart from
> suppressing.
> 
> Ismael
> 
> On Fri, Jun 21, 2019 at 4:00 AM Andy Coates <an...@confluent.io> wrote:
> 
>> Hi Ismael,
>>
>> I’m happy enough to not deprecate the existing `AdminClient` class as part
>> of this change.
>>
>> However, note that, the class will likely be empty, i.e. all methods and
>> implementations will be inherited from the interface:
>>
>> public abstract class AdminClient implements Admin {
>> }
>>
>> Not marking it as deprecated has the benefit that users won’t see any
>> deprecation warnings on the next release. Conversely, deprecating it will
>> mean we can choose to remove this, now pointless class, in the future if we
>> choose.
>>
>> That’s my thinking for deprecation, but as I’ve said I’m happy either way.
>>
>> Andy
>>
>>> On 18 Jun 2019, at 16:09, Ismael Juma <is...@juma.me.uk> wrote:
>>>
>>> I agree with Ryanne, I think we should avoid deprecating AdminClient and
>>> causing so much churn for users who don't actually care about this niche
>>> use case.
>>>
>>> Ismael
>>>
>>> On Tue, Jun 18, 2019 at 6:43 AM Andy Coates <an...@confluent.io> wrote:
>>>
>>>> Hi Ryanne,
>>>>
>>>> If we don't change the client code, then everywhere will still expect
>>>> subclasses of `AdminClient`, so the interface will be of no use, i.e. I
>>>> can't write a class that implements the new interface and pass it to the
>>>> client code.
>>>>
>>>> Thanks,
>>>>
>>>> Andy
>>>>
>>>> On Mon, 17 Jun 2019 at 19:01, Ryanne Dolan <ry...@gmail.com>
>> wrote:
>>>>
>>>>> Andy, while I agree that the new interface is useful, I'm not convinced
>>>>> adding an interface requires deprecating AdminClient and changing so
>> much
>>>>> client code. Why not just add the Admin interface, have AdminClient
>>>>> implement it, and have done?
>>>>>
>>>>> Ryanne
>>>>>
>>>>> On Mon, Jun 17, 2019 at 12:09 PM Andy Coates <an...@confluent.io>
>> wrote:
>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> I think I've addressed all concerns. Let me know if I've not.  Can I
>>>> call
>>>>>> another round of votes please?
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Andy
>>>>>>
>>>>>> On Fri, 14 Jun 2019 at 04:55, Satish Duggana <
>> satish.duggana@gmail.com
>>>>>
>>>>>> wrote:
>>>>>>
>>>>>>> Hi Andy,
>>>>>>> Thanks for the KIP. This is a good change and it gives the user a
>>>>> better
>>>>>>> handle on Admin client usage. I agree with the proposal except the
>>>> new
>>>>>>> `Admin` interface having all the methods from `AdminClient` abstract
>>>>>> class.
>>>>>>> It should be kept clean having only the admin operations as methods
>>>>> from
>>>>>>> KafkaClient abstract class but not the factory methods as mentioned
>>>> in
>>>>>> the
>>>>>>> earlier mail.
>>>>>>>
>>>>>>> I know about dynamic proxies(which were widely used in RMI/EJB
>>>> world).
>>>>> I
>>>>>> am
>>>>>>> curious about the usecase using dynamic proxies with Admin client
>>>>>>> interface. Dynamic proxy can have performance penalty if it is used
>>>> in
>>>>>>> critical path. Is that the primary motivation for creating the KIP?
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Satish.
>>>>>>>
>>>>>>> On Wed, Jun 12, 2019 at 8:43 PM Andy Coates <an...@confluent.io>
>>>> wrote:
>>>>>>>
>>>>>>>> I'm not married to that part.  That was only done to keep it more
>>>> or
>>>>>> less
>>>>>>>> inline with what's already there, (an abstract class that has a
>>>>> factory
>>>>>>>> method that returns a subclass.... sounds like the same
>>>> anti-pattern
>>>>>> ;))
>>>>>>>>
>>>>>>>> An alternative would to have an `AdminClients` utility class to
>>>>> create
>>>>>>> the
>>>>>>>> admin client.
>>>>>>>>
>>>>>>>> On Mon, 10 Jun 2019 at 19:31, Matthias J. Sax <
>>>> matthias@confluent.io
>>>>>>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Hmmm...
>>>>>>>>>
>>>>>>>>> So the new interface, returns an instance of a class that
>>>>> implements
>>>>>>> the
>>>>>>>>> interface. This sounds a little bit like an anti-pattern?
>>>> Shouldn't
>>>>>>>>> interfaces actually not know anything about classes that
>>>> implement
>>>>>> the
>>>>>>>>> interface?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> -Matthias
>>>>>>>>>
>>>>>>>>> On 6/10/19 11:22 AM, Andy Coates wrote:
>>>>>>>>>> `AdminClient` would be deprecated purely because it would no
>>>>> longer
>>>>>>>> serve
>>>>>>>>>> any purpose and would be virtually empty, getting all of its
>>>>>>>>> implementation
>>>>>>>>>> from the new interfar. It would be nice to remove this from the
>>>>> API
>>>>>>> at
>>>>>>>>> the
>>>>>>>>>> next major version bump, hence the need to deprecate.
>>>>>>>>>>
>>>>>>>>>> `AdminClient.create()` would return what it does today, (so
>>>> not a
>>>>>>>>> breaking
>>>>>>>>>> change).
>>>>>>>>>>
>>>>>>>>>> On Tue, 4 Jun 2019 at 22:24, Ryanne Dolan <
>>>> ryannedolan@gmail.com
>>>>>>
>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>>> The existing `AdminClient` will be marked as deprecated.
>>>>>>>>>>>
>>>>>>>>>>> What's the reasoning behind this? I'm fine with the other
>>>>> changes,
>>>>>>> but
>>>>>>>>>>> would prefer to keep the existing public API intact if it's
>>>> not
>>>>>>>> hurting
>>>>>>>>>>> anything.
>>>>>>>>>>>
>>>>>>>>>>> Also, what will AdminClient.create() return? Would it be a
>>>>>> breaking
>>>>>>>>> change?
>>>>>>>>>>>
>>>>>>>>>>> Ryanne
>>>>>>>>>>>
>>>>>>>>>>> On Tue, Jun 4, 2019, 11:17 AM Andy Coates <an...@confluent.io>
>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Hi folks
>>>>>>>>>>>>
>>>>>>>>>>>> As there's been no chatter on this KIP I'm assuming it's
>>>>>>>>> non-contentious,
>>>>>>>>>>>> (or just boring), hence I'd like to call a vote for KIP-476:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>> https://cwiki.apache.org/confluence/display/KAFKA/KIP-476%3A+Add+Java+AdminClient+Interface
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>
>>>>>>>>>>>> Andy
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>
>>
>

Re: [VOTE] KIP-476: Add Java AdminClient interface

Posted by Ismael Juma <is...@juma.me.uk>.

This is even more reason not to deprecate immediately, there is very little
maintenance cost for us. We should be mindful that many of our users (eg
Spark, Flink, etc.) typically allow users to specify the kafka clients
version and hence avoid using new classes/interfaces for some time. They
would get a bunch of warnings they cannot do anything about apart from
suppressing.

Ismael

On Fri, Jun 21, 2019 at 4:00 AM Andy Coates <an...@confluent.io> wrote:

> Hi Ismael,
>
> I’m happy enough to not deprecate the existing `AdminClient` class as part
> of this change.
>
> However, note that, the class will likely be empty, i.e. all methods and
> implementations will be inherited from the interface:
>
> public abstract class AdminClient implements Admin {
> }
>
> Not marking it as deprecated has the benefit that users won’t see any
> deprecation warnings on the next release. Conversely, deprecating it will
> mean we can choose to remove this, now pointless class, in the future if we
> choose.
>
> That’s my thinking for deprecation, but as I’ve said I’m happy either way.
>
> Andy
>
> > On 18 Jun 2019, at 16:09, Ismael Juma <is...@juma.me.uk> wrote:
> >
> > I agree with Ryanne, I think we should avoid deprecating AdminClient and
> > causing so much churn for users who don't actually care about this niche
> > use case.
> >
> > Ismael
> >
> > On Tue, Jun 18, 2019 at 6:43 AM Andy Coates <an...@confluent.io> wrote:
> >
> >> Hi Ryanne,
> >>
> >> If we don't change the client code, then everywhere will still expect
> >> subclasses of `AdminClient`, so the interface will be of no use, i.e. I
> >> can't write a class that implements the new interface and pass it to the
> >> client code.
> >>
> >> Thanks,
> >>
> >> Andy
> >>
> >> On Mon, 17 Jun 2019 at 19:01, Ryanne Dolan <ry...@gmail.com>
> wrote:
> >>
> >>> Andy, while I agree that the new interface is useful, I'm not convinced
> >>> adding an interface requires deprecating AdminClient and changing so
> much
> >>> client code. Why not just add the Admin interface, have AdminClient
> >>> implement it, and have done?
> >>>
> >>> Ryanne
> >>>
> >>> On Mon, Jun 17, 2019 at 12:09 PM Andy Coates <an...@confluent.io>
> wrote:
> >>>
> >>>> Hi all,
> >>>>
> >>>> I think I've addressed all concerns. Let me know if I've not.  Can I
> >> call
> >>>> another round of votes please?
> >>>>
> >>>> Thanks,
> >>>>
> >>>> Andy
> >>>>
> >>>> On Fri, 14 Jun 2019 at 04:55, Satish Duggana <
> satish.duggana@gmail.com
> >>>
> >>>> wrote:
> >>>>
> >>>>> Hi Andy,
> >>>>> Thanks for the KIP. This is a good change and it gives the user a
> >>> better
> >>>>> handle on Admin client usage. I agree with the proposal except the
> >> new
> >>>>> `Admin` interface having all the methods from `AdminClient` abstract
> >>>> class.
> >>>>> It should be kept clean having only the admin operations as methods
> >>> from
> >>>>> KafkaClient abstract class but not the factory methods as mentioned
> >> in
> >>>> the
> >>>>> earlier mail.
> >>>>>
> >>>>> I know about dynamic proxies(which were widely used in RMI/EJB
> >> world).
> >>> I
> >>>> am
> >>>>> curious about the usecase using dynamic proxies with Admin client
> >>>>> interface. Dynamic proxy can have performance penalty if it is used
> >> in
> >>>>> critical path. Is that the primary motivation for creating the KIP?
> >>>>>
> >>>>> Thanks,
> >>>>> Satish.
> >>>>>
> >>>>> On Wed, Jun 12, 2019 at 8:43 PM Andy Coates <an...@confluent.io>
> >> wrote:
> >>>>>
> >>>>>> I'm not married to that part.  That was only done to keep it more
> >> or
> >>>> less
> >>>>>> inline with what's already there, (an abstract class that has a
> >>> factory
> >>>>>> method that returns a subclass.... sounds like the same
> >> anti-pattern
> >>>> ;))
> >>>>>>
> >>>>>> An alternative would to have an `AdminClients` utility class to
> >>> create
> >>>>> the
> >>>>>> admin client.
> >>>>>>
> >>>>>> On Mon, 10 Jun 2019 at 19:31, Matthias J. Sax <
> >> matthias@confluent.io
> >>>>
> >>>>>> wrote:
> >>>>>>
> >>>>>>> Hmmm...
> >>>>>>>
> >>>>>>> So the new interface, returns an instance of a class that
> >>> implements
> >>>>> the
> >>>>>>> interface. This sounds a little bit like an anti-pattern?
> >> Shouldn't
> >>>>>>> interfaces actually not know anything about classes that
> >> implement
> >>>> the
> >>>>>>> interface?
> >>>>>>>
> >>>>>>>
> >>>>>>> -Matthias
> >>>>>>>
> >>>>>>> On 6/10/19 11:22 AM, Andy Coates wrote:
> >>>>>>>> `AdminClient` would be deprecated purely because it would no
> >>> longer
> >>>>>> serve
> >>>>>>>> any purpose and would be virtually empty, getting all of its
> >>>>>>> implementation
> >>>>>>>> from the new interfar. It would be nice to remove this from the
> >>> API
> >>>>> at
> >>>>>>> the
> >>>>>>>> next major version bump, hence the need to deprecate.
> >>>>>>>>
> >>>>>>>> `AdminClient.create()` would return what it does today, (so
> >> not a
> >>>>>>> breaking
> >>>>>>>> change).
> >>>>>>>>
> >>>>>>>> On Tue, 4 Jun 2019 at 22:24, Ryanne Dolan <
> >> ryannedolan@gmail.com
> >>>>
> >>>>>> wrote:
> >>>>>>>>
> >>>>>>>>>> The existing `AdminClient` will be marked as deprecated.
> >>>>>>>>>
> >>>>>>>>> What's the reasoning behind this? I'm fine with the other
> >>> changes,
> >>>>> but
> >>>>>>>>> would prefer to keep the existing public API intact if it's
> >> not
> >>>>>> hurting
> >>>>>>>>> anything.
> >>>>>>>>>
> >>>>>>>>> Also, what will AdminClient.create() return? Would it be a
> >>>> breaking
> >>>>>>> change?
> >>>>>>>>>
> >>>>>>>>> Ryanne
> >>>>>>>>>
> >>>>>>>>> On Tue, Jun 4, 2019, 11:17 AM Andy Coates <an...@confluent.io>
> >>>>> wrote:
> >>>>>>>>>
> >>>>>>>>>> Hi folks
> >>>>>>>>>>
> >>>>>>>>>> As there's been no chatter on this KIP I'm assuming it's
> >>>>>>> non-contentious,
> >>>>>>>>>> (or just boring), hence I'd like to call a vote for KIP-476:
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-476%3A+Add+Java+AdminClient+Interface
> >>>>>>>>>>
> >>>>>>>>>> Thanks,
> >>>>>>>>>>
> >>>>>>>>>> Andy
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
>
>

Re: [VOTE] KIP-476: Add Java AdminClient interface

Posted by Andy Coates <an...@confluent.io>.

Hi Ismael,

I’m happy enough to not deprecate the existing `AdminClient` class as part of this change.

However, note that, the class will likely be empty, i.e. all methods and implementations will be inherited from the interface:

public abstract class AdminClient implements Admin {
}

Not marking it as deprecated has the benefit that users won’t see any deprecation warnings on the next release. Conversely, deprecating it will mean we can choose to remove this, now pointless class, in the future if we choose. 

That’s my thinking for deprecation, but as I’ve said I’m happy either way.

Andy

> On 18 Jun 2019, at 16:09, Ismael Juma <is...@juma.me.uk> wrote:
> 
> I agree with Ryanne, I think we should avoid deprecating AdminClient and
> causing so much churn for users who don't actually care about this niche
> use case.
> 
> Ismael
> 
> On Tue, Jun 18, 2019 at 6:43 AM Andy Coates <an...@confluent.io> wrote:
> 
>> Hi Ryanne,
>> 
>> If we don't change the client code, then everywhere will still expect
>> subclasses of `AdminClient`, so the interface will be of no use, i.e. I
>> can't write a class that implements the new interface and pass it to the
>> client code.
>> 
>> Thanks,
>> 
>> Andy
>> 
>> On Mon, 17 Jun 2019 at 19:01, Ryanne Dolan <ry...@gmail.com> wrote:
>> 
>>> Andy, while I agree that the new interface is useful, I'm not convinced
>>> adding an interface requires deprecating AdminClient and changing so much
>>> client code. Why not just add the Admin interface, have AdminClient
>>> implement it, and have done?
>>> 
>>> Ryanne
>>> 
>>> On Mon, Jun 17, 2019 at 12:09 PM Andy Coates <an...@confluent.io> wrote:
>>> 
>>>> Hi all,
>>>> 
>>>> I think I've addressed all concerns. Let me know if I've not.  Can I
>> call
>>>> another round of votes please?
>>>> 
>>>> Thanks,
>>>> 
>>>> Andy
>>>> 
>>>> On Fri, 14 Jun 2019 at 04:55, Satish Duggana <satish.duggana@gmail.com
>>> 
>>>> wrote:
>>>> 
>>>>> Hi Andy,
>>>>> Thanks for the KIP. This is a good change and it gives the user a
>>> better
>>>>> handle on Admin client usage. I agree with the proposal except the
>> new
>>>>> `Admin` interface having all the methods from `AdminClient` abstract
>>>> class.
>>>>> It should be kept clean having only the admin operations as methods
>>> from
>>>>> KafkaClient abstract class but not the factory methods as mentioned
>> in
>>>> the
>>>>> earlier mail.
>>>>> 
>>>>> I know about dynamic proxies(which were widely used in RMI/EJB
>> world).
>>> I
>>>> am
>>>>> curious about the usecase using dynamic proxies with Admin client
>>>>> interface. Dynamic proxy can have performance penalty if it is used
>> in
>>>>> critical path. Is that the primary motivation for creating the KIP?
>>>>> 
>>>>> Thanks,
>>>>> Satish.
>>>>> 
>>>>> On Wed, Jun 12, 2019 at 8:43 PM Andy Coates <an...@confluent.io>
>> wrote:
>>>>> 
>>>>>> I'm not married to that part.  That was only done to keep it more
>> or
>>>> less
>>>>>> inline with what's already there, (an abstract class that has a
>>> factory
>>>>>> method that returns a subclass.... sounds like the same
>> anti-pattern
>>>> ;))
>>>>>> 
>>>>>> An alternative would to have an `AdminClients` utility class to
>>> create
>>>>> the
>>>>>> admin client.
>>>>>> 
>>>>>> On Mon, 10 Jun 2019 at 19:31, Matthias J. Sax <
>> matthias@confluent.io
>>>> 
>>>>>> wrote:
>>>>>> 
>>>>>>> Hmmm...
>>>>>>> 
>>>>>>> So the new interface, returns an instance of a class that
>>> implements
>>>>> the
>>>>>>> interface. This sounds a little bit like an anti-pattern?
>> Shouldn't
>>>>>>> interfaces actually not know anything about classes that
>> implement
>>>> the
>>>>>>> interface?
>>>>>>> 
>>>>>>> 
>>>>>>> -Matthias
>>>>>>> 
>>>>>>> On 6/10/19 11:22 AM, Andy Coates wrote:
>>>>>>>> `AdminClient` would be deprecated purely because it would no
>>> longer
>>>>>> serve
>>>>>>>> any purpose and would be virtually empty, getting all of its
>>>>>>> implementation
>>>>>>>> from the new interfar. It would be nice to remove this from the
>>> API
>>>>> at
>>>>>>> the
>>>>>>>> next major version bump, hence the need to deprecate.
>>>>>>>> 
>>>>>>>> `AdminClient.create()` would return what it does today, (so
>> not a
>>>>>>> breaking
>>>>>>>> change).
>>>>>>>> 
>>>>>>>> On Tue, 4 Jun 2019 at 22:24, Ryanne Dolan <
>> ryannedolan@gmail.com
>>>> 
>>>>>> wrote:
>>>>>>>> 
>>>>>>>>>> The existing `AdminClient` will be marked as deprecated.
>>>>>>>>> 
>>>>>>>>> What's the reasoning behind this? I'm fine with the other
>>> changes,
>>>>> but
>>>>>>>>> would prefer to keep the existing public API intact if it's
>> not
>>>>>> hurting
>>>>>>>>> anything.
>>>>>>>>> 
>>>>>>>>> Also, what will AdminClient.create() return? Would it be a
>>>> breaking
>>>>>>> change?
>>>>>>>>> 
>>>>>>>>> Ryanne
>>>>>>>>> 
>>>>>>>>> On Tue, Jun 4, 2019, 11:17 AM Andy Coates <an...@confluent.io>
>>>>> wrote:
>>>>>>>>> 
>>>>>>>>>> Hi folks
>>>>>>>>>> 
>>>>>>>>>> As there's been no chatter on this KIP I'm assuming it's
>>>>>>> non-contentious,
>>>>>>>>>> (or just boring), hence I'd like to call a vote for KIP-476:
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> 
>> https://cwiki.apache.org/confluence/display/KAFKA/KIP-476%3A+Add+Java+AdminClient+Interface
>>>>>>>>>> 
>>>>>>>>>> Thanks,
>>>>>>>>>> 
>>>>>>>>>> Andy
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> 
>>

Re: [VOTE] KIP-476: Add Java AdminClient interface

Posted by Ismael Juma <is...@juma.me.uk>.

I agree with Ryanne, I think we should avoid deprecating AdminClient and
causing so much churn for users who don't actually care about this niche
use case.

Ismael

On Tue, Jun 18, 2019 at 6:43 AM Andy Coates <an...@confluent.io> wrote:

> Hi Ryanne,
>
> If we don't change the client code, then everywhere will still expect
> subclasses of `AdminClient`, so the interface will be of no use, i.e. I
> can't write a class that implements the new interface and pass it to the
> client code.
>
> Thanks,
>
> Andy
>
> On Mon, 17 Jun 2019 at 19:01, Ryanne Dolan <ry...@gmail.com> wrote:
>
> > Andy, while I agree that the new interface is useful, I'm not convinced
> > adding an interface requires deprecating AdminClient and changing so much
> > client code. Why not just add the Admin interface, have AdminClient
> > implement it, and have done?
> >
> > Ryanne
> >
> > On Mon, Jun 17, 2019 at 12:09 PM Andy Coates <an...@confluent.io> wrote:
> >
> > > Hi all,
> > >
> > > I think I've addressed all concerns. Let me know if I've not.  Can I
> call
> > > another round of votes please?
> > >
> > > Thanks,
> > >
> > > Andy
> > >
> > > On Fri, 14 Jun 2019 at 04:55, Satish Duggana <satish.duggana@gmail.com
> >
> > > wrote:
> > >
> > > > Hi Andy,
> > > > Thanks for the KIP. This is a good change and it gives the user a
> > better
> > > > handle on Admin client usage. I agree with the proposal except the
> new
> > > > `Admin` interface having all the methods from `AdminClient` abstract
> > > class.
> > > > It should be kept clean having only the admin operations as methods
> > from
> > > > KafkaClient abstract class but not the factory methods as mentioned
> in
> > > the
> > > > earlier mail.
> > > >
> > > > I know about dynamic proxies(which were widely used in RMI/EJB
> world).
> > I
> > > am
> > > > curious about the usecase using dynamic proxies with Admin client
> > > > interface. Dynamic proxy can have performance penalty if it is used
> in
> > > > critical path. Is that the primary motivation for creating the KIP?
> > > >
> > > > Thanks,
> > > > Satish.
> > > >
> > > > On Wed, Jun 12, 2019 at 8:43 PM Andy Coates <an...@confluent.io>
> wrote:
> > > >
> > > > > I'm not married to that part.  That was only done to keep it more
> or
> > > less
> > > > > inline with what's already there, (an abstract class that has a
> > factory
> > > > > method that returns a subclass.... sounds like the same
> anti-pattern
> > > ;))
> > > > >
> > > > > An alternative would to have an `AdminClients` utility class to
> > create
> > > > the
> > > > > admin client.
> > > > >
> > > > > On Mon, 10 Jun 2019 at 19:31, Matthias J. Sax <
> matthias@confluent.io
> > >
> > > > > wrote:
> > > > >
> > > > > > Hmmm...
> > > > > >
> > > > > > So the new interface, returns an instance of a class that
> > implements
> > > > the
> > > > > > interface. This sounds a little bit like an anti-pattern?
> Shouldn't
> > > > > > interfaces actually not know anything about classes that
> implement
> > > the
> > > > > > interface?
> > > > > >
> > > > > >
> > > > > > -Matthias
> > > > > >
> > > > > > On 6/10/19 11:22 AM, Andy Coates wrote:
> > > > > > > `AdminClient` would be deprecated purely because it would no
> > longer
> > > > > serve
> > > > > > > any purpose and would be virtually empty, getting all of its
> > > > > > implementation
> > > > > > > from the new interfar. It would be nice to remove this from the
> > API
> > > > at
> > > > > > the
> > > > > > > next major version bump, hence the need to deprecate.
> > > > > > >
> > > > > > > `AdminClient.create()` would return what it does today, (so
> not a
> > > > > > breaking
> > > > > > > change).
> > > > > > >
> > > > > > > On Tue, 4 Jun 2019 at 22:24, Ryanne Dolan <
> ryannedolan@gmail.com
> > >
> > > > > wrote:
> > > > > > >
> > > > > > >>> The existing `AdminClient` will be marked as deprecated.
> > > > > > >>
> > > > > > >> What's the reasoning behind this? I'm fine with the other
> > changes,
> > > > but
> > > > > > >> would prefer to keep the existing public API intact if it's
> not
> > > > > hurting
> > > > > > >> anything.
> > > > > > >>
> > > > > > >> Also, what will AdminClient.create() return? Would it be a
> > > breaking
> > > > > > change?
> > > > > > >>
> > > > > > >> Ryanne
> > > > > > >>
> > > > > > >> On Tue, Jun 4, 2019, 11:17 AM Andy Coates <an...@confluent.io>
> > > > wrote:
> > > > > > >>
> > > > > > >>> Hi folks
> > > > > > >>>
> > > > > > >>> As there's been no chatter on this KIP I'm assuming it's
> > > > > > non-contentious,
> > > > > > >>> (or just boring), hence I'd like to call a vote for KIP-476:
> > > > > > >>>
> > > > > > >>>
> > > > > > >>>
> > > > > >
> > > > >
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-476%3A+Add+Java+AdminClient+Interface
> > > > > > >>>
> > > > > > >>> Thanks,
> > > > > > >>>
> > > > > > >>> Andy
> > > > > > >>>
> > > > > > >>
> > > > > > >
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: [VOTE] KIP-476: Add Java AdminClient interface

Posted by Andy Coates <an...@confluent.io>.

Hi Ryanne,

If we don't change the client code, then everywhere will still expect
subclasses of `AdminClient`, so the interface will be of no use, i.e. I
can't write a class that implements the new interface and pass it to the
client code.

Thanks,

Andy

On Mon, 17 Jun 2019 at 19:01, Ryanne Dolan <ry...@gmail.com> wrote:

> Andy, while I agree that the new interface is useful, I'm not convinced
> adding an interface requires deprecating AdminClient and changing so much
> client code. Why not just add the Admin interface, have AdminClient
> implement it, and have done?
>
> Ryanne
>
> On Mon, Jun 17, 2019 at 12:09 PM Andy Coates <an...@confluent.io> wrote:
>
> > Hi all,
> >
> > I think I've addressed all concerns. Let me know if I've not.  Can I call
> > another round of votes please?
> >
> > Thanks,
> >
> > Andy
> >
> > On Fri, 14 Jun 2019 at 04:55, Satish Duggana <sa...@gmail.com>
> > wrote:
> >
> > > Hi Andy,
> > > Thanks for the KIP. This is a good change and it gives the user a
> better
> > > handle on Admin client usage. I agree with the proposal except the new
> > > `Admin` interface having all the methods from `AdminClient` abstract
> > class.
> > > It should be kept clean having only the admin operations as methods
> from
> > > KafkaClient abstract class but not the factory methods as mentioned in
> > the
> > > earlier mail.
> > >
> > > I know about dynamic proxies(which were widely used in RMI/EJB world).
> I
> > am
> > > curious about the usecase using dynamic proxies with Admin client
> > > interface. Dynamic proxy can have performance penalty if it is used in
> > > critical path. Is that the primary motivation for creating the KIP?
> > >
> > > Thanks,
> > > Satish.
> > >
> > > On Wed, Jun 12, 2019 at 8:43 PM Andy Coates <an...@confluent.io> wrote:
> > >
> > > > I'm not married to that part.  That was only done to keep it more or
> > less
> > > > inline with what's already there, (an abstract class that has a
> factory
> > > > method that returns a subclass.... sounds like the same anti-pattern
> > ;))
> > > >
> > > > An alternative would to have an `AdminClients` utility class to
> create
> > > the
> > > > admin client.
> > > >
> > > > On Mon, 10 Jun 2019 at 19:31, Matthias J. Sax <matthias@confluent.io
> >
> > > > wrote:
> > > >
> > > > > Hmmm...
> > > > >
> > > > > So the new interface, returns an instance of a class that
> implements
> > > the
> > > > > interface. This sounds a little bit like an anti-pattern? Shouldn't
> > > > > interfaces actually not know anything about classes that implement
> > the
> > > > > interface?
> > > > >
> > > > >
> > > > > -Matthias
> > > > >
> > > > > On 6/10/19 11:22 AM, Andy Coates wrote:
> > > > > > `AdminClient` would be deprecated purely because it would no
> longer
> > > > serve
> > > > > > any purpose and would be virtually empty, getting all of its
> > > > > implementation
> > > > > > from the new interfar. It would be nice to remove this from the
> API
> > > at
> > > > > the
> > > > > > next major version bump, hence the need to deprecate.
> > > > > >
> > > > > > `AdminClient.create()` would return what it does today, (so not a
> > > > > breaking
> > > > > > change).
> > > > > >
> > > > > > On Tue, 4 Jun 2019 at 22:24, Ryanne Dolan <ryannedolan@gmail.com
> >
> > > > wrote:
> > > > > >
> > > > > >>> The existing `AdminClient` will be marked as deprecated.
> > > > > >>
> > > > > >> What's the reasoning behind this? I'm fine with the other
> changes,
> > > but
> > > > > >> would prefer to keep the existing public API intact if it's not
> > > > hurting
> > > > > >> anything.
> > > > > >>
> > > > > >> Also, what will AdminClient.create() return? Would it be a
> > breaking
> > > > > change?
> > > > > >>
> > > > > >> Ryanne
> > > > > >>
> > > > > >> On Tue, Jun 4, 2019, 11:17 AM Andy Coates <an...@confluent.io>
> > > wrote:
> > > > > >>
> > > > > >>> Hi folks
> > > > > >>>
> > > > > >>> As there's been no chatter on this KIP I'm assuming it's
> > > > > non-contentious,
> > > > > >>> (or just boring), hence I'd like to call a vote for KIP-476:
> > > > > >>>
> > > > > >>>
> > > > > >>>
> > > > >
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-476%3A+Add+Java+AdminClient+Interface
> > > > > >>>
> > > > > >>> Thanks,
> > > > > >>>
> > > > > >>> Andy
> > > > > >>>
> > > > > >>
> > > > > >
> > > > >
> > > > >
> > > >
> > >
> >
>

Re: [VOTE] KIP-476: Add Java AdminClient interface

Posted by Ryanne Dolan <ry...@gmail.com>.

Andy, while I agree that the new interface is useful, I'm not convinced
adding an interface requires deprecating AdminClient and changing so much
client code. Why not just add the Admin interface, have AdminClient
implement it, and have done?

Ryanne

On Mon, Jun 17, 2019 at 12:09 PM Andy Coates <an...@confluent.io> wrote:

> Hi all,
>
> I think I've addressed all concerns. Let me know if I've not.  Can I call
> another round of votes please?
>
> Thanks,
>
> Andy
>
> On Fri, 14 Jun 2019 at 04:55, Satish Duggana <sa...@gmail.com>
> wrote:
>
> > Hi Andy,
> > Thanks for the KIP. This is a good change and it gives the user a better
> > handle on Admin client usage. I agree with the proposal except the new
> > `Admin` interface having all the methods from `AdminClient` abstract
> class.
> > It should be kept clean having only the admin operations as methods from
> > KafkaClient abstract class but not the factory methods as mentioned in
> the
> > earlier mail.
> >
> > I know about dynamic proxies(which were widely used in RMI/EJB world). I
> am
> > curious about the usecase using dynamic proxies with Admin client
> > interface. Dynamic proxy can have performance penalty if it is used in
> > critical path. Is that the primary motivation for creating the KIP?
> >
> > Thanks,
> > Satish.
> >
> > On Wed, Jun 12, 2019 at 8:43 PM Andy Coates <an...@confluent.io> wrote:
> >
> > > I'm not married to that part.  That was only done to keep it more or
> less
> > > inline with what's already there, (an abstract class that has a factory
> > > method that returns a subclass.... sounds like the same anti-pattern
> ;))
> > >
> > > An alternative would to have an `AdminClients` utility class to create
> > the
> > > admin client.
> > >
> > > On Mon, 10 Jun 2019 at 19:31, Matthias J. Sax <ma...@confluent.io>
> > > wrote:
> > >
> > > > Hmmm...
> > > >
> > > > So the new interface, returns an instance of a class that implements
> > the
> > > > interface. This sounds a little bit like an anti-pattern? Shouldn't
> > > > interfaces actually not know anything about classes that implement
> the
> > > > interface?
> > > >
> > > >
> > > > -Matthias
> > > >
> > > > On 6/10/19 11:22 AM, Andy Coates wrote:
> > > > > `AdminClient` would be deprecated purely because it would no longer
> > > serve
> > > > > any purpose and would be virtually empty, getting all of its
> > > > implementation
> > > > > from the new interfar. It would be nice to remove this from the API
> > at
> > > > the
> > > > > next major version bump, hence the need to deprecate.
> > > > >
> > > > > `AdminClient.create()` would return what it does today, (so not a
> > > > breaking
> > > > > change).
> > > > >
> > > > > On Tue, 4 Jun 2019 at 22:24, Ryanne Dolan <ry...@gmail.com>
> > > wrote:
> > > > >
> > > > >>> The existing `AdminClient` will be marked as deprecated.
> > > > >>
> > > > >> What's the reasoning behind this? I'm fine with the other changes,
> > but
> > > > >> would prefer to keep the existing public API intact if it's not
> > > hurting
> > > > >> anything.
> > > > >>
> > > > >> Also, what will AdminClient.create() return? Would it be a
> breaking
> > > > change?
> > > > >>
> > > > >> Ryanne
> > > > >>
> > > > >> On Tue, Jun 4, 2019, 11:17 AM Andy Coates <an...@confluent.io>
> > wrote:
> > > > >>
> > > > >>> Hi folks
> > > > >>>
> > > > >>> As there's been no chatter on this KIP I'm assuming it's
> > > > non-contentious,
> > > > >>> (or just boring), hence I'd like to call a vote for KIP-476:
> > > > >>>
> > > > >>>
> > > > >>>
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-476%3A+Add+Java+AdminClient+Interface
> > > > >>>
> > > > >>> Thanks,
> > > > >>>
> > > > >>> Andy
> > > > >>>
> > > > >>
> > > > >
> > > >
> > > >
> > >
> >
>

Re: [VOTE] KIP-476: Add Java AdminClient interface

Posted by Andy Coates <an...@confluent.io>.

Hi all,

I think I've addressed all concerns. Let me know if I've not.  Can I call
another round of votes please?

Thanks,

Andy

On Fri, 14 Jun 2019 at 04:55, Satish Duggana <sa...@gmail.com>
wrote:

> Hi Andy,
> Thanks for the KIP. This is a good change and it gives the user a better
> handle on Admin client usage. I agree with the proposal except the new
> `Admin` interface having all the methods from `AdminClient` abstract class.
> It should be kept clean having only the admin operations as methods from
> KafkaClient abstract class but not the factory methods as mentioned in the
> earlier mail.
>
> I know about dynamic proxies(which were widely used in RMI/EJB world). I am
> curious about the usecase using dynamic proxies with Admin client
> interface. Dynamic proxy can have performance penalty if it is used in
> critical path. Is that the primary motivation for creating the KIP?
>
> Thanks,
> Satish.
>
> On Wed, Jun 12, 2019 at 8:43 PM Andy Coates <an...@confluent.io> wrote:
>
> > I'm not married to that part.  That was only done to keep it more or less
> > inline with what's already there, (an abstract class that has a factory
> > method that returns a subclass.... sounds like the same anti-pattern ;))
> >
> > An alternative would to have an `AdminClients` utility class to create
> the
> > admin client.
> >
> > On Mon, 10 Jun 2019 at 19:31, Matthias J. Sax <ma...@confluent.io>
> > wrote:
> >
> > > Hmmm...
> > >
> > > So the new interface, returns an instance of a class that implements
> the
> > > interface. This sounds a little bit like an anti-pattern? Shouldn't
> > > interfaces actually not know anything about classes that implement the
> > > interface?
> > >
> > >
> > > -Matthias
> > >
> > > On 6/10/19 11:22 AM, Andy Coates wrote:
> > > > `AdminClient` would be deprecated purely because it would no longer
> > serve
> > > > any purpose and would be virtually empty, getting all of its
> > > implementation
> > > > from the new interfar. It would be nice to remove this from the API
> at
> > > the
> > > > next major version bump, hence the need to deprecate.
> > > >
> > > > `AdminClient.create()` would return what it does today, (so not a
> > > breaking
> > > > change).
> > > >
> > > > On Tue, 4 Jun 2019 at 22:24, Ryanne Dolan <ry...@gmail.com>
> > wrote:
> > > >
> > > >>> The existing `AdminClient` will be marked as deprecated.
> > > >>
> > > >> What's the reasoning behind this? I'm fine with the other changes,
> but
> > > >> would prefer to keep the existing public API intact if it's not
> > hurting
> > > >> anything.
> > > >>
> > > >> Also, what will AdminClient.create() return? Would it be a breaking
> > > change?
> > > >>
> > > >> Ryanne
> > > >>
> > > >> On Tue, Jun 4, 2019, 11:17 AM Andy Coates <an...@confluent.io>
> wrote:
> > > >>
> > > >>> Hi folks
> > > >>>
> > > >>> As there's been no chatter on this KIP I'm assuming it's
> > > non-contentious,
> > > >>> (or just boring), hence I'd like to call a vote for KIP-476:
> > > >>>
> > > >>>
> > > >>>
> > >
> >
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-476%3A+Add+Java+AdminClient+Interface
> > > >>>
> > > >>> Thanks,
> > > >>>
> > > >>> Andy
> > > >>>
> > > >>
> > > >
> > >
> > >
> >
>

Re: [VOTE] KIP-476: Add Java AdminClient interface

Posted by Ismael Juma <is...@juma.me.uk>.

Hi Andy,

I didn't see any reason being mentioned why it's an anti pattern or cleaner
so I assume it's subjective. :) For what it's worth, the approach of a
collection interface providing a default implementation is very common in
Scala and it makes a lot of sense in my mind. For example, why does
everyone have to decide the List implementation, ArrayList is the best
default and it should just be chosen for the common case.

Having a separate class with the same name and a suffix at the end just
adds complexity and surface area while making it less discoverable for very
little benefit in my opinion.

Ismael

On Fri, Jun 21, 2019 at 3:56 AM Andy Coates <an...@confluent.io> wrote:

> Hi Ismael,
>
> Matthias thought having the interface also provide a factory method that
> returns a specific implementation was a bit of an anti-pattern, and I would
> tend to agree, though I’ve used this same pattern myself at times where the
> set of implementations is known.
>
> Matthias may want to answer with his own thoughts, but from my own
> experience I’ve often found it cleaner to have a companion utility class to
> an interface in an API, that has factory methods to create instances of the
> common set of implementations. In this case it would be `KafkaAdminClient`
> only at the moment, though if we were to support something like the
> `DelegatingAdminClient` that Colin mentioned in the future, this too could
> be on the utility class.
>
> My preference is the separate classes. But in the interest of moving this
> forward I’m happy with either.
>
> Andy
>
>
>
> > On 18 Jun 2019, at 16:07, Ismael Juma <is...@juma.me.uk> wrote:
> >
> > I don't agree with this change. The idea that an interface cannot have a
> > default implementation is outdated in my view. Can someone provide any
> > benefit to introducing a separate class for the factory method?
> >
> > Ismael
> >
> > On Mon, Jun 17, 2019 at 10:07 AM Andy Coates <an...@confluent.io> wrote:
> >
> >> Hi All,
> >>
> >> I've updated the KIP to move the `create` factory method implementation
> >> into a new `AdminClients` utility class, rather than on the new `Admin`
> >> interface.
> >>
> >> Satish,
> >>
> >> As above, the KIP has been updated to only have the operations on the
> >> `Admin` api. As for the overhead of dynamic proxies... the use of
> dynamic
> >> proxies is totally up to the users of the library. In KSQL we use
> dynamic
> >> proxies because the overhead is acceptable and it decouples us from
> >> additions to the client interfaces. Others may decide otherwise for
> their
> >> project. By making the admin api an interface we're empowering users to
> >> choose the right approach for them.
> >>
> >> This is the primary motivation for the KIP from my point of view.
> However,
> >> it also brings it inline with the other Kafka clients, and gives users
> the
> >> freedom to do what they want, rather than requiring the use of an
> abstract
> >> base class.
> >>
> >> Thanks,
> >>
> >> Andy
> >>
> >>
> >> On Fri, 14 Jun 2019 at 04:55, Satish Duggana <sa...@gmail.com>
> >> wrote:
> >>
> >>> Hi Andy,
> >>> Thanks for the KIP. This is a good change and it gives the user a
> better
> >>> handle on Admin client usage. I agree with the proposal except the new
> >>> `Admin` interface having all the methods from `AdminClient` abstract
> >> class.
> >>> It should be kept clean having only the admin operations as methods
> from
> >>> KafkaClient abstract class but not the factory methods as mentioned in
> >> the
> >>> earlier mail.
> >>>
> >>> I know about dynamic proxies(which were widely used in RMI/EJB world).
> I
> >> am
> >>> curious about the usecase using dynamic proxies with Admin client
> >>> interface. Dynamic proxy can have performance penalty if it is used in
> >>> critical path. Is that the primary motivation for creating the KIP?
> >>>
> >>> Thanks,
> >>> Satish.
> >>>
> >>> On Wed, Jun 12, 2019 at 8:43 PM Andy Coates <an...@confluent.io> wrote:
> >>>
> >>>> I'm not married to that part.  That was only done to keep it more or
> >> less
> >>>> inline with what's already there, (an abstract class that has a
> factory
> >>>> method that returns a subclass.... sounds like the same anti-pattern
> >> ;))
> >>>>
> >>>> An alternative would to have an `AdminClients` utility class to create
> >>> the
> >>>> admin client.
> >>>>
> >>>> On Mon, 10 Jun 2019 at 19:31, Matthias J. Sax <ma...@confluent.io>
> >>>> wrote:
> >>>>
> >>>>> Hmmm...
> >>>>>
> >>>>> So the new interface, returns an instance of a class that implements
> >>> the
> >>>>> interface. This sounds a little bit like an anti-pattern? Shouldn't
> >>>>> interfaces actually not know anything about classes that implement
> >> the
> >>>>> interface?
> >>>>>
> >>>>>
> >>>>> -Matthias
> >>>>>
> >>>>> On 6/10/19 11:22 AM, Andy Coates wrote:
> >>>>>> `AdminClient` would be deprecated purely because it would no longer
> >>>> serve
> >>>>>> any purpose and would be virtually empty, getting all of its
> >>>>> implementation
> >>>>>> from the new interfar. It would be nice to remove this from the API
> >>> at
> >>>>> the
> >>>>>> next major version bump, hence the need to deprecate.
> >>>>>>
> >>>>>> `AdminClient.create()` would return what it does today, (so not a
> >>>>> breaking
> >>>>>> change).
> >>>>>>
> >>>>>> On Tue, 4 Jun 2019 at 22:24, Ryanne Dolan <ry...@gmail.com>
> >>>> wrote:
> >>>>>>
> >>>>>>>> The existing `AdminClient` will be marked as deprecated.
> >>>>>>>
> >>>>>>> What's the reasoning behind this? I'm fine with the other changes,
> >>> but
> >>>>>>> would prefer to keep the existing public API intact if it's not
> >>>> hurting
> >>>>>>> anything.
> >>>>>>>
> >>>>>>> Also, what will AdminClient.create() return? Would it be a
> >> breaking
> >>>>> change?
> >>>>>>>
> >>>>>>> Ryanne
> >>>>>>>
> >>>>>>> On Tue, Jun 4, 2019, 11:17 AM Andy Coates <an...@confluent.io>
> >>> wrote:
> >>>>>>>
> >>>>>>>> Hi folks
> >>>>>>>>
> >>>>>>>> As there's been no chatter on this KIP I'm assuming it's
> >>>>> non-contentious,
> >>>>>>>> (or just boring), hence I'd like to call a vote for KIP-476:
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>
> >>>>
> >>>
> >>
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-476%3A+Add+Java+AdminClient+Interface
> >>>>>>>>
> >>>>>>>> Thanks,
> >>>>>>>>
> >>>>>>>> Andy
> >>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>
> >>>
> >>
>
>

Re: [VOTE] KIP-476: Add Java AdminClient interface

Posted by Andy Coates <an...@confluent.io>.

Hi Ismael,

Matthias thought having the interface also provide a factory method that returns a specific implementation was a bit of an anti-pattern, and I would tend to agree, though I’ve used this same pattern myself at times where the set of implementations is known.

Matthias may want to answer with his own thoughts, but from my own experience I’ve often found it cleaner to have a companion utility class to an interface in an API, that has factory methods to create instances of the common set of implementations. In this case it would be `KafkaAdminClient` only at the moment, though if we were to support something like the `DelegatingAdminClient` that Colin mentioned in the future, this too could be on the utility class.

My preference is the separate classes. But in the interest of moving this forward I’m happy with either.

Andy



> On 18 Jun 2019, at 16:07, Ismael Juma <is...@juma.me.uk> wrote:
> 
> I don't agree with this change. The idea that an interface cannot have a
> default implementation is outdated in my view. Can someone provide any
> benefit to introducing a separate class for the factory method?
> 
> Ismael
> 
> On Mon, Jun 17, 2019 at 10:07 AM Andy Coates <an...@confluent.io> wrote:
> 
>> Hi All,
>> 
>> I've updated the KIP to move the `create` factory method implementation
>> into a new `AdminClients` utility class, rather than on the new `Admin`
>> interface.
>> 
>> Satish,
>> 
>> As above, the KIP has been updated to only have the operations on the
>> `Admin` api. As for the overhead of dynamic proxies... the use of dynamic
>> proxies is totally up to the users of the library. In KSQL we use dynamic
>> proxies because the overhead is acceptable and it decouples us from
>> additions to the client interfaces. Others may decide otherwise for their
>> project. By making the admin api an interface we're empowering users to
>> choose the right approach for them.
>> 
>> This is the primary motivation for the KIP from my point of view. However,
>> it also brings it inline with the other Kafka clients, and gives users the
>> freedom to do what they want, rather than requiring the use of an abstract
>> base class.
>> 
>> Thanks,
>> 
>> Andy
>> 
>> 
>> On Fri, 14 Jun 2019 at 04:55, Satish Duggana <sa...@gmail.com>
>> wrote:
>> 
>>> Hi Andy,
>>> Thanks for the KIP. This is a good change and it gives the user a better
>>> handle on Admin client usage. I agree with the proposal except the new
>>> `Admin` interface having all the methods from `AdminClient` abstract
>> class.
>>> It should be kept clean having only the admin operations as methods from
>>> KafkaClient abstract class but not the factory methods as mentioned in
>> the
>>> earlier mail.
>>> 
>>> I know about dynamic proxies(which were widely used in RMI/EJB world). I
>> am
>>> curious about the usecase using dynamic proxies with Admin client
>>> interface. Dynamic proxy can have performance penalty if it is used in
>>> critical path. Is that the primary motivation for creating the KIP?
>>> 
>>> Thanks,
>>> Satish.
>>> 
>>> On Wed, Jun 12, 2019 at 8:43 PM Andy Coates <an...@confluent.io> wrote:
>>> 
>>>> I'm not married to that part.  That was only done to keep it more or
>> less
>>>> inline with what's already there, (an abstract class that has a factory
>>>> method that returns a subclass.... sounds like the same anti-pattern
>> ;))
>>>> 
>>>> An alternative would to have an `AdminClients` utility class to create
>>> the
>>>> admin client.
>>>> 
>>>> On Mon, 10 Jun 2019 at 19:31, Matthias J. Sax <ma...@confluent.io>
>>>> wrote:
>>>> 
>>>>> Hmmm...
>>>>> 
>>>>> So the new interface, returns an instance of a class that implements
>>> the
>>>>> interface. This sounds a little bit like an anti-pattern? Shouldn't
>>>>> interfaces actually not know anything about classes that implement
>> the
>>>>> interface?
>>>>> 
>>>>> 
>>>>> -Matthias
>>>>> 
>>>>> On 6/10/19 11:22 AM, Andy Coates wrote:
>>>>>> `AdminClient` would be deprecated purely because it would no longer
>>>> serve
>>>>>> any purpose and would be virtually empty, getting all of its
>>>>> implementation
>>>>>> from the new interfar. It would be nice to remove this from the API
>>> at
>>>>> the
>>>>>> next major version bump, hence the need to deprecate.
>>>>>> 
>>>>>> `AdminClient.create()` would return what it does today, (so not a
>>>>> breaking
>>>>>> change).
>>>>>> 
>>>>>> On Tue, 4 Jun 2019 at 22:24, Ryanne Dolan <ry...@gmail.com>
>>>> wrote:
>>>>>> 
>>>>>>>> The existing `AdminClient` will be marked as deprecated.
>>>>>>> 
>>>>>>> What's the reasoning behind this? I'm fine with the other changes,
>>> but
>>>>>>> would prefer to keep the existing public API intact if it's not
>>>> hurting
>>>>>>> anything.
>>>>>>> 
>>>>>>> Also, what will AdminClient.create() return? Would it be a
>> breaking
>>>>> change?
>>>>>>> 
>>>>>>> Ryanne
>>>>>>> 
>>>>>>> On Tue, Jun 4, 2019, 11:17 AM Andy Coates <an...@confluent.io>
>>> wrote:
>>>>>>> 
>>>>>>>> Hi folks
>>>>>>>> 
>>>>>>>> As there's been no chatter on this KIP I'm assuming it's
>>>>> non-contentious,
>>>>>>>> (or just boring), hence I'd like to call a vote for KIP-476:
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>> 
>>>> 
>>> 
>> https://cwiki.apache.org/confluence/display/KAFKA/KIP-476%3A+Add+Java+AdminClient+Interface
>>>>>>>> 
>>>>>>>> Thanks,
>>>>>>>> 
>>>>>>>> Andy
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>>>> 
>>>> 
>>> 
>>

Re: [VOTE] KIP-476: Add Java AdminClient interface

Posted by Ismael Juma <is...@juma.me.uk>.

I don't agree with this change. The idea that an interface cannot have a
default implementation is outdated in my view. Can someone provide any
benefit to introducing a separate class for the factory method?

Ismael

On Mon, Jun 17, 2019 at 10:07 AM Andy Coates <an...@confluent.io> wrote:

> Hi All,
>
> I've updated the KIP to move the `create` factory method implementation
> into a new `AdminClients` utility class, rather than on the new `Admin`
> interface.
>
> Satish,
>
> As above, the KIP has been updated to only have the operations on the
> `Admin` api. As for the overhead of dynamic proxies... the use of dynamic
> proxies is totally up to the users of the library. In KSQL we use dynamic
> proxies because the overhead is acceptable and it decouples us from
> additions to the client interfaces. Others may decide otherwise for their
> project. By making the admin api an interface we're empowering users to
> choose the right approach for them.
>
> This is the primary motivation for the KIP from my point of view. However,
> it also brings it inline with the other Kafka clients, and gives users the
> freedom to do what they want, rather than requiring the use of an abstract
> base class.
>
> Thanks,
>
> Andy
>
>
> On Fri, 14 Jun 2019 at 04:55, Satish Duggana <sa...@gmail.com>
> wrote:
>
> > Hi Andy,
> > Thanks for the KIP. This is a good change and it gives the user a better
> > handle on Admin client usage. I agree with the proposal except the new
> > `Admin` interface having all the methods from `AdminClient` abstract
> class.
> > It should be kept clean having only the admin operations as methods from
> > KafkaClient abstract class but not the factory methods as mentioned in
> the
> > earlier mail.
> >
> > I know about dynamic proxies(which were widely used in RMI/EJB world). I
> am
> > curious about the usecase using dynamic proxies with Admin client
> > interface. Dynamic proxy can have performance penalty if it is used in
> > critical path. Is that the primary motivation for creating the KIP?
> >
> > Thanks,
> > Satish.
> >
> > On Wed, Jun 12, 2019 at 8:43 PM Andy Coates <an...@confluent.io> wrote:
> >
> > > I'm not married to that part.  That was only done to keep it more or
> less
> > > inline with what's already there, (an abstract class that has a factory
> > > method that returns a subclass.... sounds like the same anti-pattern
> ;))
> > >
> > > An alternative would to have an `AdminClients` utility class to create
> > the
> > > admin client.
> > >
> > > On Mon, 10 Jun 2019 at 19:31, Matthias J. Sax <ma...@confluent.io>
> > > wrote:
> > >
> > > > Hmmm...
> > > >
> > > > So the new interface, returns an instance of a class that implements
> > the
> > > > interface. This sounds a little bit like an anti-pattern? Shouldn't
> > > > interfaces actually not know anything about classes that implement
> the
> > > > interface?
> > > >
> > > >
> > > > -Matthias
> > > >
> > > > On 6/10/19 11:22 AM, Andy Coates wrote:
> > > > > `AdminClient` would be deprecated purely because it would no longer
> > > serve
> > > > > any purpose and would be virtually empty, getting all of its
> > > > implementation
> > > > > from the new interfar. It would be nice to remove this from the API
> > at
> > > > the
> > > > > next major version bump, hence the need to deprecate.
> > > > >
> > > > > `AdminClient.create()` would return what it does today, (so not a
> > > > breaking
> > > > > change).
> > > > >
> > > > > On Tue, 4 Jun 2019 at 22:24, Ryanne Dolan <ry...@gmail.com>
> > > wrote:
> > > > >
> > > > >>> The existing `AdminClient` will be marked as deprecated.
> > > > >>
> > > > >> What's the reasoning behind this? I'm fine with the other changes,
> > but
> > > > >> would prefer to keep the existing public API intact if it's not
> > > hurting
> > > > >> anything.
> > > > >>
> > > > >> Also, what will AdminClient.create() return? Would it be a
> breaking
> > > > change?
> > > > >>
> > > > >> Ryanne
> > > > >>
> > > > >> On Tue, Jun 4, 2019, 11:17 AM Andy Coates <an...@confluent.io>
> > wrote:
> > > > >>
> > > > >>> Hi folks
> > > > >>>
> > > > >>> As there's been no chatter on this KIP I'm assuming it's
> > > > non-contentious,
> > > > >>> (or just boring), hence I'd like to call a vote for KIP-476:
> > > > >>>
> > > > >>>
> > > > >>>
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-476%3A+Add+Java+AdminClient+Interface
> > > > >>>
> > > > >>> Thanks,
> > > > >>>
> > > > >>> Andy
> > > > >>>
> > > > >>
> > > > >
> > > >
> > > >
> > >
> >
>

Re: [VOTE] KIP-476: Add Java AdminClient interface

Posted by Andy Coates <an...@confluent.io>.

Hi All,

I've updated the KIP to move the `create` factory method implementation
into a new `AdminClients` utility class, rather than on the new `Admin`
interface.

Satish,

As above, the KIP has been updated to only have the operations on the
`Admin` api. As for the overhead of dynamic proxies... the use of dynamic
proxies is totally up to the users of the library. In KSQL we use dynamic
proxies because the overhead is acceptable and it decouples us from
additions to the client interfaces. Others may decide otherwise for their
project. By making the admin api an interface we're empowering users to
choose the right approach for them.

This is the primary motivation for the KIP from my point of view. However,
it also brings it inline with the other Kafka clients, and gives users the
freedom to do what they want, rather than requiring the use of an abstract
base class.

Thanks,

Andy


On Fri, 14 Jun 2019 at 04:55, Satish Duggana <sa...@gmail.com>
wrote:

> Hi Andy,
> Thanks for the KIP. This is a good change and it gives the user a better
> handle on Admin client usage. I agree with the proposal except the new
> `Admin` interface having all the methods from `AdminClient` abstract class.
> It should be kept clean having only the admin operations as methods from
> KafkaClient abstract class but not the factory methods as mentioned in the
> earlier mail.
>
> I know about dynamic proxies(which were widely used in RMI/EJB world). I am
> curious about the usecase using dynamic proxies with Admin client
> interface. Dynamic proxy can have performance penalty if it is used in
> critical path. Is that the primary motivation for creating the KIP?
>
> Thanks,
> Satish.
>
> On Wed, Jun 12, 2019 at 8:43 PM Andy Coates <an...@confluent.io> wrote:
>
> > I'm not married to that part.  That was only done to keep it more or less
> > inline with what's already there, (an abstract class that has a factory
> > method that returns a subclass.... sounds like the same anti-pattern ;))
> >
> > An alternative would to have an `AdminClients` utility class to create
> the
> > admin client.
> >
> > On Mon, 10 Jun 2019 at 19:31, Matthias J. Sax <ma...@confluent.io>
> > wrote:
> >
> > > Hmmm...
> > >
> > > So the new interface, returns an instance of a class that implements
> the
> > > interface. This sounds a little bit like an anti-pattern? Shouldn't
> > > interfaces actually not know anything about classes that implement the
> > > interface?
> > >
> > >
> > > -Matthias
> > >
> > > On 6/10/19 11:22 AM, Andy Coates wrote:
> > > > `AdminClient` would be deprecated purely because it would no longer
> > serve
> > > > any purpose and would be virtually empty, getting all of its
> > > implementation
> > > > from the new interfar. It would be nice to remove this from the API
> at
> > > the
> > > > next major version bump, hence the need to deprecate.
> > > >
> > > > `AdminClient.create()` would return what it does today, (so not a
> > > breaking
> > > > change).
> > > >
> > > > On Tue, 4 Jun 2019 at 22:24, Ryanne Dolan <ry...@gmail.com>
> > wrote:
> > > >
> > > >>> The existing `AdminClient` will be marked as deprecated.
> > > >>
> > > >> What's the reasoning behind this? I'm fine with the other changes,
> but
> > > >> would prefer to keep the existing public API intact if it's not
> > hurting
> > > >> anything.
> > > >>
> > > >> Also, what will AdminClient.create() return? Would it be a breaking
> > > change?
> > > >>
> > > >> Ryanne
> > > >>
> > > >> On Tue, Jun 4, 2019, 11:17 AM Andy Coates <an...@confluent.io>
> wrote:
> > > >>
> > > >>> Hi folks
> > > >>>
> > > >>> As there's been no chatter on this KIP I'm assuming it's
> > > non-contentious,
> > > >>> (or just boring), hence I'd like to call a vote for KIP-476:
> > > >>>
> > > >>>
> > > >>>
> > >
> >
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-476%3A+Add+Java+AdminClient+Interface
> > > >>>
> > > >>> Thanks,
> > > >>>
> > > >>> Andy
> > > >>>
> > > >>
> > > >
> > >
> > >
> >
>

Re: [VOTE] KIP-476: Add Java AdminClient interface

Posted by Satish Duggana <sa...@gmail.com>.

Hi Andy,
Thanks for the KIP. This is a good change and it gives the user a better
handle on Admin client usage. I agree with the proposal except the new
`Admin` interface having all the methods from `AdminClient` abstract class.
It should be kept clean having only the admin operations as methods from
KafkaClient abstract class but not the factory methods as mentioned in the
earlier mail.

I know about dynamic proxies(which were widely used in RMI/EJB world). I am
curious about the usecase using dynamic proxies with Admin client
interface. Dynamic proxy can have performance penalty if it is used in
critical path. Is that the primary motivation for creating the KIP?

Thanks,
Satish.

On Wed, Jun 12, 2019 at 8:43 PM Andy Coates <an...@confluent.io> wrote:

> I'm not married to that part.  That was only done to keep it more or less
> inline with what's already there, (an abstract class that has a factory
> method that returns a subclass.... sounds like the same anti-pattern ;))
>
> An alternative would to have an `AdminClients` utility class to create the
> admin client.
>
> On Mon, 10 Jun 2019 at 19:31, Matthias J. Sax <ma...@confluent.io>
> wrote:
>
> > Hmmm...
> >
> > So the new interface, returns an instance of a class that implements the
> > interface. This sounds a little bit like an anti-pattern? Shouldn't
> > interfaces actually not know anything about classes that implement the
> > interface?
> >
> >
> > -Matthias
> >
> > On 6/10/19 11:22 AM, Andy Coates wrote:
> > > `AdminClient` would be deprecated purely because it would no longer
> serve
> > > any purpose and would be virtually empty, getting all of its
> > implementation
> > > from the new interfar. It would be nice to remove this from the API at
> > the
> > > next major version bump, hence the need to deprecate.
> > >
> > > `AdminClient.create()` would return what it does today, (so not a
> > breaking
> > > change).
> > >
> > > On Tue, 4 Jun 2019 at 22:24, Ryanne Dolan <ry...@gmail.com>
> wrote:
> > >
> > >>> The existing `AdminClient` will be marked as deprecated.
> > >>
> > >> What's the reasoning behind this? I'm fine with the other changes, but
> > >> would prefer to keep the existing public API intact if it's not
> hurting
> > >> anything.
> > >>
> > >> Also, what will AdminClient.create() return? Would it be a breaking
> > change?
> > >>
> > >> Ryanne
> > >>
> > >> On Tue, Jun 4, 2019, 11:17 AM Andy Coates <an...@confluent.io> wrote:
> > >>
> > >>> Hi folks
> > >>>
> > >>> As there's been no chatter on this KIP I'm assuming it's
> > non-contentious,
> > >>> (or just boring), hence I'd like to call a vote for KIP-476:
> > >>>
> > >>>
> > >>>
> >
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-476%3A+Add+Java+AdminClient+Interface
> > >>>
> > >>> Thanks,
> > >>>
> > >>> Andy
> > >>>
> > >>
> > >
> >
> >
>

Re: [VOTE] KIP-476: Add Java AdminClient interface

Posted by Andy Coates <an...@confluent.io>.

I'm not married to that part.  That was only done to keep it more or less
inline with what's already there, (an abstract class that has a factory
method that returns a subclass.... sounds like the same anti-pattern ;))

An alternative would to have an `AdminClients` utility class to create the
admin client.

On Mon, 10 Jun 2019 at 19:31, Matthias J. Sax <ma...@confluent.io> wrote:

> Hmmm...
>
> So the new interface, returns an instance of a class that implements the
> interface. This sounds a little bit like an anti-pattern? Shouldn't
> interfaces actually not know anything about classes that implement the
> interface?
>
>
> -Matthias
>
> On 6/10/19 11:22 AM, Andy Coates wrote:
> > `AdminClient` would be deprecated purely because it would no longer serve
> > any purpose and would be virtually empty, getting all of its
> implementation
> > from the new interfar. It would be nice to remove this from the API at
> the
> > next major version bump, hence the need to deprecate.
> >
> > `AdminClient.create()` would return what it does today, (so not a
> breaking
> > change).
> >
> > On Tue, 4 Jun 2019 at 22:24, Ryanne Dolan <ry...@gmail.com> wrote:
> >
> >>> The existing `AdminClient` will be marked as deprecated.
> >>
> >> What's the reasoning behind this? I'm fine with the other changes, but
> >> would prefer to keep the existing public API intact if it's not hurting
> >> anything.
> >>
> >> Also, what will AdminClient.create() return? Would it be a breaking
> change?
> >>
> >> Ryanne
> >>
> >> On Tue, Jun 4, 2019, 11:17 AM Andy Coates <an...@confluent.io> wrote:
> >>
> >>> Hi folks
> >>>
> >>> As there's been no chatter on this KIP I'm assuming it's
> non-contentious,
> >>> (or just boring), hence I'd like to call a vote for KIP-476:
> >>>
> >>>
> >>>
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-476%3A+Add+Java+AdminClient+Interface
> >>>
> >>> Thanks,
> >>>
> >>> Andy
> >>>
> >>
> >
>
>

Re: [VOTE] KIP-476: Add Java AdminClient interface

Posted by "Matthias J. Sax" <ma...@confluent.io>.

Hmmm...

So the new interface, returns an instance of a class that implements the
interface. This sounds a little bit like an anti-pattern? Shouldn't
interfaces actually not know anything about classes that implement the
interface?


-Matthias

On 6/10/19 11:22 AM, Andy Coates wrote:
> `AdminClient` would be deprecated purely because it would no longer serve
> any purpose and would be virtually empty, getting all of its implementation
> from the new interfar. It would be nice to remove this from the API at the
> next major version bump, hence the need to deprecate.
> 
> `AdminClient.create()` would return what it does today, (so not a breaking
> change).
> 
> On Tue, 4 Jun 2019 at 22:24, Ryanne Dolan <ry...@gmail.com> wrote:
> 
>>> The existing `AdminClient` will be marked as deprecated.
>>
>> What's the reasoning behind this? I'm fine with the other changes, but
>> would prefer to keep the existing public API intact if it's not hurting
>> anything.
>>
>> Also, what will AdminClient.create() return? Would it be a breaking change?
>>
>> Ryanne
>>
>> On Tue, Jun 4, 2019, 11:17 AM Andy Coates <an...@confluent.io> wrote:
>>
>>> Hi folks
>>>
>>> As there's been no chatter on this KIP I'm assuming it's non-contentious,
>>> (or just boring), hence I'd like to call a vote for KIP-476:
>>>
>>>
>>> https://cwiki.apache.org/confluence/display/KAFKA/KIP-476%3A+Add+Java+AdminClient+Interface
>>>
>>> Thanks,
>>>
>>> Andy
>>>
>>
>

Re: [VOTE] KIP-476: Add Java AdminClient interface

Posted by Andy Coates <an...@confluent.io>.

`AdminClient` would be deprecated purely because it would no longer serve
any purpose and would be virtually empty, getting all of its implementation
from the new interfar. It would be nice to remove this from the API at the
next major version bump, hence the need to deprecate.

`AdminClient.create()` would return what it does today, (so not a breaking
change).

On Tue, 4 Jun 2019 at 22:24, Ryanne Dolan <ry...@gmail.com> wrote:

> > The existing `AdminClient` will be marked as deprecated.
>
> What's the reasoning behind this? I'm fine with the other changes, but
> would prefer to keep the existing public API intact if it's not hurting
> anything.
>
> Also, what will AdminClient.create() return? Would it be a breaking change?
>
> Ryanne
>
> On Tue, Jun 4, 2019, 11:17 AM Andy Coates <an...@confluent.io> wrote:
>
>> Hi folks
>>
>> As there's been no chatter on this KIP I'm assuming it's non-contentious,
>> (or just boring), hence I'd like to call a vote for KIP-476:
>>
>>
>> https://cwiki.apache.org/confluence/display/KAFKA/KIP-476%3A+Add+Java+AdminClient+Interface
>>
>> Thanks,
>>
>> Andy
>>
>

Re: [VOTE] KIP-476: Add Java AdminClient interface

Posted by Ryanne Dolan <ry...@gmail.com>.

> The existing `AdminClient` will be marked as deprecated.

What's the reasoning behind this? I'm fine with the other changes, but
would prefer to keep the existing public API intact if it's not hurting
anything.

Also, what will AdminClient.create() return? Would it be a breaking change?

Ryanne

On Tue, Jun 4, 2019, 11:17 AM Andy Coates <an...@confluent.io> wrote:

> Hi folks
>
> As there's been no chatter on this KIP I'm assuming it's non-contentious,
> (or just boring), hence I'd like to call a vote for KIP-476:
>
>
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-476%3A+Add+Java+AdminClient+Interface
>
> Thanks,
>
> Andy
>