You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@kafka.apache.org by Harsha <ka...@harsha.io> on 2016/04/28 21:13:14 UTC

[DISCUSSION] KAFKA-3633. Kafka Consumer API breaking backward compatibility

Hi All,
       We noticed KIP-45 broke the compatibility with the consumer API
       that shipped in 0.9.x releases. 
Hugo posted a patch that only adds these old methods back to
KafkaConsumer.java with the deprecated tag. I would like to get this in
0.10 release so that it will help anyone who used new consumer API from
0.9 release.  Anyone has any concerns having this patch in.

Thanks,
-Harsha

Re: [DISCUSSION] KAFKA-3633. Kafka Consumer API breaking backward compatibility

Posted by Hugo Da Cruz Louro <hl...@hortonworks.com>.
Hi Jason,

In my opinion, if one changes the implementation (KafkaConsumer), one is not technically changing the API, which is the Consumer interface. That’s the reason behind coding behind interfaces, that the implementation can change, but the (public) API remains unchanged. We are not fundamentally changing the public API (Consumer interface), but rather making the existing implementation backwards compatible by supporting deprecated methods. 

Thanks, 
Hugo

> On Apr 28, 2016, at 12:45 PM, Jason Gustafson <ja...@confluent.io> wrote:
> 
> Hey Harsha,
> 
> Probably the main concern is that we already voted to do this in KIP-45.
> The compatibility concern was brought up in the discussion (I was actually
> in favor of overloading), but we ultimately decided to make the breaking
> change to keep the API small. That may or may not have been the right
> decision, but it seems like there should be a new vote to revert it, right?
> 
> Thanks,
> Jason
> 
> On Thu, Apr 28, 2016 at 12:30 PM, Hugo Da Cruz Louro <hlouro@hortonworks.com
>> wrote:
> 
>> Hello everyone,
>> 
>> I understand the concerns over making the API more confusing to new users,
>> but the current implementation<
>> https://github.com/apache/kafka/pull/1281/files> does not add any new
>> methods to the interface Consumer. It simply adds the pre-existing methods
>> with varargs parameters to the KafkaConsumer class, for backwards
>> compatibility. Since KafkaConsumer isat this point is the only production
>> implementation of the Consumer interface, this change makes it easy to use
>> these methods in existing clients. Furthermore, in addition to the methods
>> not being exposed in the interface, they are marked as @Deprecated.
>> 
>> Thanks,
>> Hugo
>> 
>> On Apr 28, 2016, at 12:13 PM, Harsha <kafka@harsha.io<mailto:
>> kafka@harsha.io>> wrote:
>> 
>> Hi All,
>>      We noticed KIP-45 broke the compatibility with the consumer API
>>      that shipped in 0.9.x releases.
>> Hugo posted a patch that only adds these old methods back to
>> KafkaConsumer.java with the deprecated tag. I would like to get this in
>> 0.10 release so that it will help anyone who used new consumer API from
>> 0.9 release.  Anyone has any concerns having this patch in.
>> 
>> Thanks,
>> -Harsha
>> 
>> 
>> 


Re: [DISCUSSION] KAFKA-3633. Kafka Consumer API breaking backward compatibility

Posted by Harsha <ma...@harsha.io>.
Hi Jason,
              Agree and its my bad to not to raise this during the
              voting of KIP-45. Which I missed it.
We can definitely start a vote around it.

Thanks,
Harsha

On Thu, Apr 28, 2016, at 12:45 PM, Jason Gustafson wrote:
> Hey Harsha,
> 
> Probably the main concern is that we already voted to do this in KIP-45.
> The compatibility concern was brought up in the discussion (I was
> actually
> in favor of overloading), but we ultimately decided to make the breaking
> change to keep the API small. That may or may not have been the right
> decision, but it seems like there should be a new vote to revert it,
> right?
> 
> Thanks,
> Jason
> 
> On Thu, Apr 28, 2016 at 12:30 PM, Hugo Da Cruz Louro
> <hlouro@hortonworks.com
> > wrote:
> 
> > Hello everyone,
> >
> > I understand the concerns over making the API more confusing to new users,
> > but the current implementation<
> > https://github.com/apache/kafka/pull/1281/files> does not add any new
> > methods to the interface Consumer. It simply adds the pre-existing methods
> > with varargs parameters to the KafkaConsumer class, for backwards
> > compatibility. Since KafkaConsumer isat this point is the only production
> > implementation of the Consumer interface, this change makes it easy to use
> > these methods in existing clients. Furthermore, in addition to the methods
> > not being exposed in the interface, they are marked as @Deprecated.
> >
> > Thanks,
> > Hugo
> >
> > On Apr 28, 2016, at 12:13 PM, Harsha <kafka@harsha.io<mailto:
> > kafka@harsha.io>> wrote:
> >
> > Hi All,
> >       We noticed KIP-45 broke the compatibility with the consumer API
> >       that shipped in 0.9.x releases.
> > Hugo posted a patch that only adds these old methods back to
> > KafkaConsumer.java with the deprecated tag. I would like to get this in
> > 0.10 release so that it will help anyone who used new consumer API from
> > 0.9 release.  Anyone has any concerns having this patch in.
> >
> > Thanks,
> > -Harsha
> >
> >
> >

Re: [DISCUSSION] KAFKA-3633. Kafka Consumer API breaking backward compatibility

Posted by Jason Gustafson <ja...@confluent.io>.
Hey Harsha,

Probably the main concern is that we already voted to do this in KIP-45.
The compatibility concern was brought up in the discussion (I was actually
in favor of overloading), but we ultimately decided to make the breaking
change to keep the API small. That may or may not have been the right
decision, but it seems like there should be a new vote to revert it, right?

Thanks,
Jason

On Thu, Apr 28, 2016 at 12:30 PM, Hugo Da Cruz Louro <hlouro@hortonworks.com
> wrote:

> Hello everyone,
>
> I understand the concerns over making the API more confusing to new users,
> but the current implementation<
> https://github.com/apache/kafka/pull/1281/files> does not add any new
> methods to the interface Consumer. It simply adds the pre-existing methods
> with varargs parameters to the KafkaConsumer class, for backwards
> compatibility. Since KafkaConsumer isat this point is the only production
> implementation of the Consumer interface, this change makes it easy to use
> these methods in existing clients. Furthermore, in addition to the methods
> not being exposed in the interface, they are marked as @Deprecated.
>
> Thanks,
> Hugo
>
> On Apr 28, 2016, at 12:13 PM, Harsha <kafka@harsha.io<mailto:
> kafka@harsha.io>> wrote:
>
> Hi All,
>       We noticed KIP-45 broke the compatibility with the consumer API
>       that shipped in 0.9.x releases.
> Hugo posted a patch that only adds these old methods back to
> KafkaConsumer.java with the deprecated tag. I would like to get this in
> 0.10 release so that it will help anyone who used new consumer API from
> 0.9 release.  Anyone has any concerns having this patch in.
>
> Thanks,
> -Harsha
>
>
>

Re: [DISCUSSION] KAFKA-3633. Kafka Consumer API breaking backward compatibility

Posted by Hugo Da Cruz Louro <hl...@hortonworks.com>.
Hello everyone,

I understand the concerns over making the API more confusing to new users, but the current implementation<https://github.com/apache/kafka/pull/1281/files> does not add any new methods to the interface Consumer. It simply adds the pre-existing methods with varargs parameters to the KafkaConsumer class, for backwards compatibility. Since KafkaConsumer isat this point is the only production implementation of the Consumer interface, this change makes it easy to use these methods in existing clients. Furthermore, in addition to the methods not being exposed in the interface, they are marked as @Deprecated.

Thanks,
Hugo

On Apr 28, 2016, at 12:13 PM, Harsha <ka...@harsha.io>> wrote:

Hi All,
      We noticed KIP-45 broke the compatibility with the consumer API
      that shipped in 0.9.x releases.
Hugo posted a patch that only adds these old methods back to
KafkaConsumer.java with the deprecated tag. I would like to get this in
0.10 release so that it will help anyone who used new consumer API from
0.9 release.  Anyone has any concerns having this patch in.

Thanks,
-Harsha