You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@kafka.apache.org by Sean McCauliff <se...@gmail.com> on 2016/12/02 00:40:40 UTC
Re: [DISCUSS] 0.10.1.1 Plan
Well I would like KAFKA-4250 (make ProducerRecord and ConsumerRecord
extensible) in the 0.10.1 branch if is not a big deal. They are just
dumb structs. But they are final so no extensibility is possible.
Sean
On Tue, Nov 29, 2016 at 5:32 PM, Ignacio Solis <is...@igso.net> wrote:
> I don't think anybody from LinkedIn asked for features on this release. We
> just jumped in at the discussion of including a patch which was not a bug
> fix and whether it mattered.
>
> Having said that, the internal release we're working on came off the 0.10.1
> branch with a few internal hotfix patches and a few cherry picked fixes...
> Including the final keyword removal patch.
>
> Nacho
>
> On Tue, Nov 29, 2016, 5:15 PM Gwen Shapira <gw...@confluent.io> wrote:
>
>> btw. is LinkedIn no longer running from trunk? I'm not used to
>> LinkedIn employees requesting specific patches to be included in a
>> bugfix release.
>>
>> Any discussion on the content of any release is obviously welcome, I'm
>> just wondering if there was a change in policy.
>>
>> On Tue, Nov 29, 2016 at 2:17 PM, Ismael Juma <is...@juma.me.uk> wrote:
>> > OK, so it seems like there are no changes that break compatibility in the
>> > 0.10.1 branch since we offer no compatibility guarantees for logging
>> > output. That's good. :)
>> >
>> > About the removal of final, it happened in trunk and it doesn't seem like
>> > anyone is still asking for it to be included in the 0.10.1 branch so it
>> is
>> > indeed not important for this bug fix release (I thought we had
>> established
>> > that quite a while ago).
>> >
>> > Ismael
>> >
>> > On Tue, Nov 29, 2016 at 9:35 PM, Ignacio Solis <is...@igso.net> wrote:
>> >
>> >> Sorry, that was a hasty reply. There are also various logging things
>> that
>> >> change format. This could break parsers.
>> >>
>> >> None of them are important, my only argument is that the final keyword
>> >> removal is not important either.
>> >>
>> >> Nacho
>> >>
>> >>
>> >> On Tue, Nov 29, 2016 at 1:25 PM, Ignacio Solis <is...@igso.net> wrote:
>> >>
>> >> > https://git-wip-us.apache.org/repos/asf?p=kafka.git;a=commit;h=
>> >> > 10cfc1628df024f7596d3af5c168fa90f59035ca
>> >> >
>> >> > On Tue, Nov 29, 2016 at 1:24 PM, Ismael Juma <is...@juma.me.uk>
>> wrote:
>> >> >
>> >> >> Which changes break compatibility in the 0.10.1 branch? It would be
>> good
>> >> >> to
>> >> >> fix before the release goes out.
>> >> >>
>> >> >> Ismael
>> >> >>
>> >> >> On 29 Nov 2016 9:09 pm, "Ignacio Solis" <is...@igso.net> wrote:
>> >> >>
>> >> >> > Some of the changes in the 0.10.1 branch already are not bug fixes.
>> >> Some
>> >> >> > break compatibility.
>> >> >> >
>> >> >> > Having said that, at this level we should maintain a stable API and
>> >> >> leave
>> >> >> > any changes for real version bumps. This should be only a bugfix
>> >> >> release.
>> >> >> >
>> >> >> > Nacho
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> > On Tue, Nov 29, 2016 at 8:35 AM, Ismael Juma <is...@juma.me.uk>
>> >> wrote:
>> >> >> >
>> >> >> > > I disagree, but let's discuss it another time and in a separate
>> >> >> thread.
>> >> >> > :)
>> >> >> > >
>> >> >> > > Ismael
>> >> >> > >
>> >> >> > > On Tue, Nov 29, 2016 at 4:30 PM, radai <
>> radai.rosenblatt@gmail.com>
>> >> >> > wrote:
>> >> >> > >
>> >> >> > > > designing kafka code for stable extensibility is a worthy and
>> >> noble
>> >> >> > > cause.
>> >> >> > > > however, seeing as there are no such derivatives out in the
>> wild
>> >> >> yet i
>> >> >> > > > think investing the effort right now is a bit premature from
>> >> kafka's
>> >> >> > pov.
>> >> >> > > > I think its enough simply not to purposefully prevent such
>> >> >> extensions.
>> >> >> > > >
>> >> >> > > > On Tue, Nov 29, 2016 at 4:05 AM, Ismael Juma <
>> ismael@juma.me.uk>
>> >> >> > wrote:
>> >> >> > > >
>> >> >> > > > > On Sat, Nov 26, 2016 at 11:08 PM, radai <
>> >> >> radai.rosenblatt@gmail.com>
>> >> >> > > > > wrote:
>> >> >> > > > >
>> >> >> > > > > > "compatibility guarantees that are expected by people who
>> >> >> subclass
>> >> >> > > > these
>> >> >> > > > > > classes"
>> >> >> > > > > >
>> >> >> > > > > > sorry if this is not the best thread for this discussion,
>> but
>> >> I
>> >> >> > just
>> >> >> > > > > wanted
>> >> >> > > > > > to pop in and say that since any subclassing of these will
>> >> >> > obviously
>> >> >> > > > not
>> >> >> > > > > be
>> >> >> > > > > > done within the kafka codebase - what guarantees are
>> needed?
>> >> >> > > > > >
>> >> >> > > > >
>> >> >> > > > > I elaborated a little in my other message in this thread. A
>> >> simple
>> >> >> > and
>> >> >> > > > > somewhat contrived example: `ConsumerRecord.toString` calls
>> the
>> >> >> > `topic`
>> >> >> > > > > method. Someone overrides the `topic` method and it all
>> works as
>> >> >> > > > expected.
>> >> >> > > > > In a subsequent release, we change `toString` to use the
>> field
>> >> >> > directly
>> >> >> > > > > (like it's done for other fields like `key` and `value`) and
>> it
>> >> >> will
>> >> >> > > > break
>> >> >> > > > > `toString` for this user. One may wonder: why would one
>> >> override a
>> >> >> > > method
>> >> >> > > > > like `topic`? That is a good question, but part of the
>> exercise
>> >> is
>> >> >> > > > deciding
>> >> >> > > > > how we approach these issues. We could make the methods final
>> >> and
>> >> >> > > > eliminate
>> >> >> > > > > the possibility, we could document it so that users can
>> choose
>> >> to
>> >> >> do
>> >> >> > > > weird
>> >> >> > > > > things if they want, etc.
>> >> >> > > > >
>> >> >> > > > > Another thing that is usually good to think about is the
>> >> >> expectation
>> >> >> > > for
>> >> >> > > > > `equals` and `hashCode`. What if subclasses implement them to
>> >> have
>> >> >> > > value
>> >> >> > > > > semantics instead of identity semantics. Is that OK or would
>> it
>> >> >> break
>> >> >> > > > > things?
>> >> >> > > > >
>> >> >> > > > > Designing for implementation inheritance is generally complex
>> >> >> > although
>> >> >> > > > for
>> >> >> > > > > simple "record" like classes, it can be easier by following a
>> >> few
>> >> >> > > > > guidelines.
>> >> >> > > > >
>> >> >> > > > > Ismael
>> >> >> > > > >
>> >> >> > > >
>> >> >> > >
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> > --
>> >> >> > Nacho - Ignacio Solis - isolis@igso.net
>> >> >> >
>> >> >>
>> >> >
>> >> >
>> >> >
>> >> > --
>> >> > Nacho - Ignacio Solis - isolis@igso.net
>> >> >
>> >>
>> >>
>> >>
>> >> --
>> >> Nacho - Ignacio Solis - isolis@igso.net
>> >>
>>
>>
>>
>> --
>> Gwen Shapira
>> Product Manager | Confluent
>> 650.450.2760 | @gwenshap
>> Follow us: Twitter | blog
>>
Re: [DISCUSS] 0.10.1.1 Plan
Posted by Guozhang Wang <wa...@gmail.com>.
Status Update:
All tasks marked for 0.10.1.1 as been resolved, will start the release
process right away.
Guozhang
On Fri, Dec 2, 2016 at 1:01 PM, Guozhang Wang <wa...@gmail.com> wrote:
> @Sean,
>
> There have been some discussions about KAFKA-4250, from Ismael. The main
> concern is on backward compatibility between 0.10.1.0 and the coming
> 0.10.1.1.
>
>
> Status Update:
>
> We are having three tasks left for 0.10.1.1, all of which have a PR under
> review and close to be merged. After those three I will start the release
> process and start a separate thread on the RC voting.
>
> https://issues.apache.org/jira/issues/?jql=project%20%
> 3D%20KAFKA%20AND%20resolution%20%3D%20Unresolved%20AND%
> 20fixVersion%20%3D%200.10.1.1%20ORDER%20BY%20priority%
> 20DESC%2C%20key%20DESC
>
>
> Guozhang
>
>
> On Thu, Dec 1, 2016 at 4:40 PM, Sean McCauliff <se...@gmail.com>
> wrote:
>
>> Well I would like KAFKA-4250 (make ProducerRecord and ConsumerRecord
>> extensible) in the 0.10.1 branch if is not a big deal. They are just
>> dumb structs. But they are final so no extensibility is possible.
>>
>> Sean
>>
>> On Tue, Nov 29, 2016 at 5:32 PM, Ignacio Solis <is...@igso.net> wrote:
>> > I don't think anybody from LinkedIn asked for features on this
>> release. We
>> > just jumped in at the discussion of including a patch which was not a
>> bug
>> > fix and whether it mattered.
>> >
>> > Having said that, the internal release we're working on came off the
>> 0.10.1
>> > branch with a few internal hotfix patches and a few cherry picked
>> fixes...
>> > Including the final keyword removal patch.
>> >
>> > Nacho
>> >
>> > On Tue, Nov 29, 2016, 5:15 PM Gwen Shapira <gw...@confluent.io> wrote:
>> >
>> >> btw. is LinkedIn no longer running from trunk? I'm not used to
>> >> LinkedIn employees requesting specific patches to be included in a
>> >> bugfix release.
>> >>
>> >> Any discussion on the content of any release is obviously welcome, I'm
>> >> just wondering if there was a change in policy.
>> >>
>> >> On Tue, Nov 29, 2016 at 2:17 PM, Ismael Juma <is...@juma.me.uk>
>> wrote:
>> >> > OK, so it seems like there are no changes that break compatibility
>> in the
>> >> > 0.10.1 branch since we offer no compatibility guarantees for logging
>> >> > output. That's good. :)
>> >> >
>> >> > About the removal of final, it happened in trunk and it doesn't seem
>> like
>> >> > anyone is still asking for it to be included in the 0.10.1 branch so
>> it
>> >> is
>> >> > indeed not important for this bug fix release (I thought we had
>> >> established
>> >> > that quite a while ago).
>> >> >
>> >> > Ismael
>> >> >
>> >> > On Tue, Nov 29, 2016 at 9:35 PM, Ignacio Solis <is...@igso.net>
>> wrote:
>> >> >
>> >> >> Sorry, that was a hasty reply. There are also various logging
>> things
>> >> that
>> >> >> change format. This could break parsers.
>> >> >>
>> >> >> None of them are important, my only argument is that the final
>> keyword
>> >> >> removal is not important either.
>> >> >>
>> >> >> Nacho
>> >> >>
>> >> >>
>> >> >> On Tue, Nov 29, 2016 at 1:25 PM, Ignacio Solis <is...@igso.net>
>> wrote:
>> >> >>
>> >> >> > https://git-wip-us.apache.org/repos/asf?p=kafka.git;a=commit;h=
>> >> >> > 10cfc1628df024f7596d3af5c168fa90f59035ca
>> >> >> >
>> >> >> > On Tue, Nov 29, 2016 at 1:24 PM, Ismael Juma <is...@juma.me.uk>
>> >> wrote:
>> >> >> >
>> >> >> >> Which changes break compatibility in the 0.10.1 branch? It would
>> be
>> >> good
>> >> >> >> to
>> >> >> >> fix before the release goes out.
>> >> >> >>
>> >> >> >> Ismael
>> >> >> >>
>> >> >> >> On 29 Nov 2016 9:09 pm, "Ignacio Solis" <is...@igso.net> wrote:
>> >> >> >>
>> >> >> >> > Some of the changes in the 0.10.1 branch already are not bug
>> fixes.
>> >> >> Some
>> >> >> >> > break compatibility.
>> >> >> >> >
>> >> >> >> > Having said that, at this level we should maintain a stable
>> API and
>> >> >> >> leave
>> >> >> >> > any changes for real version bumps. This should be only a
>> bugfix
>> >> >> >> release.
>> >> >> >> >
>> >> >> >> > Nacho
>> >> >> >> >
>> >> >> >> >
>> >> >> >> >
>> >> >> >> >
>> >> >> >> > On Tue, Nov 29, 2016 at 8:35 AM, Ismael Juma <
>> ismael@juma.me.uk>
>> >> >> wrote:
>> >> >> >> >
>> >> >> >> > > I disagree, but let's discuss it another time and in a
>> separate
>> >> >> >> thread.
>> >> >> >> > :)
>> >> >> >> > >
>> >> >> >> > > Ismael
>> >> >> >> > >
>> >> >> >> > > On Tue, Nov 29, 2016 at 4:30 PM, radai <
>> >> radai.rosenblatt@gmail.com>
>> >> >> >> > wrote:
>> >> >> >> > >
>> >> >> >> > > > designing kafka code for stable extensibility is a worthy
>> and
>> >> >> noble
>> >> >> >> > > cause.
>> >> >> >> > > > however, seeing as there are no such derivatives out in the
>> >> wild
>> >> >> >> yet i
>> >> >> >> > > > think investing the effort right now is a bit premature
>> from
>> >> >> kafka's
>> >> >> >> > pov.
>> >> >> >> > > > I think its enough simply not to purposefully prevent such
>> >> >> >> extensions.
>> >> >> >> > > >
>> >> >> >> > > > On Tue, Nov 29, 2016 at 4:05 AM, Ismael Juma <
>> >> ismael@juma.me.uk>
>> >> >> >> > wrote:
>> >> >> >> > > >
>> >> >> >> > > > > On Sat, Nov 26, 2016 at 11:08 PM, radai <
>> >> >> >> radai.rosenblatt@gmail.com>
>> >> >> >> > > > > wrote:
>> >> >> >> > > > >
>> >> >> >> > > > > > "compatibility guarantees that are expected by people
>> who
>> >> >> >> subclass
>> >> >> >> > > > these
>> >> >> >> > > > > > classes"
>> >> >> >> > > > > >
>> >> >> >> > > > > > sorry if this is not the best thread for this
>> discussion,
>> >> but
>> >> >> I
>> >> >> >> > just
>> >> >> >> > > > > wanted
>> >> >> >> > > > > > to pop in and say that since any subclassing of these
>> will
>> >> >> >> > obviously
>> >> >> >> > > > not
>> >> >> >> > > > > be
>> >> >> >> > > > > > done within the kafka codebase - what guarantees are
>> >> needed?
>> >> >> >> > > > > >
>> >> >> >> > > > >
>> >> >> >> > > > > I elaborated a little in my other message in this
>> thread. A
>> >> >> simple
>> >> >> >> > and
>> >> >> >> > > > > somewhat contrived example: `ConsumerRecord.toString`
>> calls
>> >> the
>> >> >> >> > `topic`
>> >> >> >> > > > > method. Someone overrides the `topic` method and it all
>> >> works as
>> >> >> >> > > > expected.
>> >> >> >> > > > > In a subsequent release, we change `toString` to use the
>> >> field
>> >> >> >> > directly
>> >> >> >> > > > > (like it's done for other fields like `key` and `value`)
>> and
>> >> it
>> >> >> >> will
>> >> >> >> > > > break
>> >> >> >> > > > > `toString` for this user. One may wonder: why would one
>> >> >> override a
>> >> >> >> > > method
>> >> >> >> > > > > like `topic`? That is a good question, but part of the
>> >> exercise
>> >> >> is
>> >> >> >> > > > deciding
>> >> >> >> > > > > how we approach these issues. We could make the methods
>> final
>> >> >> and
>> >> >> >> > > > eliminate
>> >> >> >> > > > > the possibility, we could document it so that users can
>> >> choose
>> >> >> to
>> >> >> >> do
>> >> >> >> > > > weird
>> >> >> >> > > > > things if they want, etc.
>> >> >> >> > > > >
>> >> >> >> > > > > Another thing that is usually good to think about is the
>> >> >> >> expectation
>> >> >> >> > > for
>> >> >> >> > > > > `equals` and `hashCode`. What if subclasses implement
>> them to
>> >> >> have
>> >> >> >> > > value
>> >> >> >> > > > > semantics instead of identity semantics. Is that OK or
>> would
>> >> it
>> >> >> >> break
>> >> >> >> > > > > things?
>> >> >> >> > > > >
>> >> >> >> > > > > Designing for implementation inheritance is generally
>> complex
>> >> >> >> > although
>> >> >> >> > > > for
>> >> >> >> > > > > simple "record" like classes, it can be easier by
>> following a
>> >> >> few
>> >> >> >> > > > > guidelines.
>> >> >> >> > > > >
>> >> >> >> > > > > Ismael
>> >> >> >> > > > >
>> >> >> >> > > >
>> >> >> >> > >
>> >> >> >> >
>> >> >> >> >
>> >> >> >> >
>> >> >> >> > --
>> >> >> >> > Nacho - Ignacio Solis - isolis@igso.net
>> >> >> >> >
>> >> >> >>
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> > --
>> >> >> > Nacho - Ignacio Solis - isolis@igso.net
>> >> >> >
>> >> >>
>> >> >>
>> >> >>
>> >> >> --
>> >> >> Nacho - Ignacio Solis - isolis@igso.net
>> >> >>
>> >>
>> >>
>> >>
>> >> --
>> >> Gwen Shapira
>> >> Product Manager | Confluent
>> >> 650.450.2760 | @gwenshap
>> >> Follow us: Twitter | blog
>> >>
>>
>
>
>
> --
> -- Guozhang
>
--
-- Guozhang
Re: [DISCUSS] 0.10.1.1 Plan
Posted by Guozhang Wang <wa...@gmail.com>.
@Sean,
There have been some discussions about KAFKA-4250, from Ismael. The main
concern is on backward compatibility between 0.10.1.0 and the coming
0.10.1.1.
Status Update:
We are having three tasks left for 0.10.1.1, all of which have a PR under
review and close to be merged. After those three I will start the release
process and start a separate thread on the RC voting.
https://issues.apache.org/jira/issues/?jql=project%20%3D%20KAFKA%20AND%20resolution%20%3D%20Unresolved%20AND%20fixVersion%20%3D%200.10.1.1%20ORDER%20BY%20priority%20DESC%2C%20key%20DESC
Guozhang
On Thu, Dec 1, 2016 at 4:40 PM, Sean McCauliff <se...@gmail.com>
wrote:
> Well I would like KAFKA-4250 (make ProducerRecord and ConsumerRecord
> extensible) in the 0.10.1 branch if is not a big deal. They are just
> dumb structs. But they are final so no extensibility is possible.
>
> Sean
>
> On Tue, Nov 29, 2016 at 5:32 PM, Ignacio Solis <is...@igso.net> wrote:
> > I don't think anybody from LinkedIn asked for features on this release.
> We
> > just jumped in at the discussion of including a patch which was not a bug
> > fix and whether it mattered.
> >
> > Having said that, the internal release we're working on came off the
> 0.10.1
> > branch with a few internal hotfix patches and a few cherry picked
> fixes...
> > Including the final keyword removal patch.
> >
> > Nacho
> >
> > On Tue, Nov 29, 2016, 5:15 PM Gwen Shapira <gw...@confluent.io> wrote:
> >
> >> btw. is LinkedIn no longer running from trunk? I'm not used to
> >> LinkedIn employees requesting specific patches to be included in a
> >> bugfix release.
> >>
> >> Any discussion on the content of any release is obviously welcome, I'm
> >> just wondering if there was a change in policy.
> >>
> >> On Tue, Nov 29, 2016 at 2:17 PM, Ismael Juma <is...@juma.me.uk> wrote:
> >> > OK, so it seems like there are no changes that break compatibility in
> the
> >> > 0.10.1 branch since we offer no compatibility guarantees for logging
> >> > output. That's good. :)
> >> >
> >> > About the removal of final, it happened in trunk and it doesn't seem
> like
> >> > anyone is still asking for it to be included in the 0.10.1 branch so
> it
> >> is
> >> > indeed not important for this bug fix release (I thought we had
> >> established
> >> > that quite a while ago).
> >> >
> >> > Ismael
> >> >
> >> > On Tue, Nov 29, 2016 at 9:35 PM, Ignacio Solis <is...@igso.net>
> wrote:
> >> >
> >> >> Sorry, that was a hasty reply. There are also various logging things
> >> that
> >> >> change format. This could break parsers.
> >> >>
> >> >> None of them are important, my only argument is that the final
> keyword
> >> >> removal is not important either.
> >> >>
> >> >> Nacho
> >> >>
> >> >>
> >> >> On Tue, Nov 29, 2016 at 1:25 PM, Ignacio Solis <is...@igso.net>
> wrote:
> >> >>
> >> >> > https://git-wip-us.apache.org/repos/asf?p=kafka.git;a=commit;h=
> >> >> > 10cfc1628df024f7596d3af5c168fa90f59035ca
> >> >> >
> >> >> > On Tue, Nov 29, 2016 at 1:24 PM, Ismael Juma <is...@juma.me.uk>
> >> wrote:
> >> >> >
> >> >> >> Which changes break compatibility in the 0.10.1 branch? It would
> be
> >> good
> >> >> >> to
> >> >> >> fix before the release goes out.
> >> >> >>
> >> >> >> Ismael
> >> >> >>
> >> >> >> On 29 Nov 2016 9:09 pm, "Ignacio Solis" <is...@igso.net> wrote:
> >> >> >>
> >> >> >> > Some of the changes in the 0.10.1 branch already are not bug
> fixes.
> >> >> Some
> >> >> >> > break compatibility.
> >> >> >> >
> >> >> >> > Having said that, at this level we should maintain a stable API
> and
> >> >> >> leave
> >> >> >> > any changes for real version bumps. This should be only a
> bugfix
> >> >> >> release.
> >> >> >> >
> >> >> >> > Nacho
> >> >> >> >
> >> >> >> >
> >> >> >> >
> >> >> >> >
> >> >> >> > On Tue, Nov 29, 2016 at 8:35 AM, Ismael Juma <ismael@juma.me.uk
> >
> >> >> wrote:
> >> >> >> >
> >> >> >> > > I disagree, but let's discuss it another time and in a
> separate
> >> >> >> thread.
> >> >> >> > :)
> >> >> >> > >
> >> >> >> > > Ismael
> >> >> >> > >
> >> >> >> > > On Tue, Nov 29, 2016 at 4:30 PM, radai <
> >> radai.rosenblatt@gmail.com>
> >> >> >> > wrote:
> >> >> >> > >
> >> >> >> > > > designing kafka code for stable extensibility is a worthy
> and
> >> >> noble
> >> >> >> > > cause.
> >> >> >> > > > however, seeing as there are no such derivatives out in the
> >> wild
> >> >> >> yet i
> >> >> >> > > > think investing the effort right now is a bit premature from
> >> >> kafka's
> >> >> >> > pov.
> >> >> >> > > > I think its enough simply not to purposefully prevent such
> >> >> >> extensions.
> >> >> >> > > >
> >> >> >> > > > On Tue, Nov 29, 2016 at 4:05 AM, Ismael Juma <
> >> ismael@juma.me.uk>
> >> >> >> > wrote:
> >> >> >> > > >
> >> >> >> > > > > On Sat, Nov 26, 2016 at 11:08 PM, radai <
> >> >> >> radai.rosenblatt@gmail.com>
> >> >> >> > > > > wrote:
> >> >> >> > > > >
> >> >> >> > > > > > "compatibility guarantees that are expected by people
> who
> >> >> >> subclass
> >> >> >> > > > these
> >> >> >> > > > > > classes"
> >> >> >> > > > > >
> >> >> >> > > > > > sorry if this is not the best thread for this
> discussion,
> >> but
> >> >> I
> >> >> >> > just
> >> >> >> > > > > wanted
> >> >> >> > > > > > to pop in and say that since any subclassing of these
> will
> >> >> >> > obviously
> >> >> >> > > > not
> >> >> >> > > > > be
> >> >> >> > > > > > done within the kafka codebase - what guarantees are
> >> needed?
> >> >> >> > > > > >
> >> >> >> > > > >
> >> >> >> > > > > I elaborated a little in my other message in this thread.
> A
> >> >> simple
> >> >> >> > and
> >> >> >> > > > > somewhat contrived example: `ConsumerRecord.toString`
> calls
> >> the
> >> >> >> > `topic`
> >> >> >> > > > > method. Someone overrides the `topic` method and it all
> >> works as
> >> >> >> > > > expected.
> >> >> >> > > > > In a subsequent release, we change `toString` to use the
> >> field
> >> >> >> > directly
> >> >> >> > > > > (like it's done for other fields like `key` and `value`)
> and
> >> it
> >> >> >> will
> >> >> >> > > > break
> >> >> >> > > > > `toString` for this user. One may wonder: why would one
> >> >> override a
> >> >> >> > > method
> >> >> >> > > > > like `topic`? That is a good question, but part of the
> >> exercise
> >> >> is
> >> >> >> > > > deciding
> >> >> >> > > > > how we approach these issues. We could make the methods
> final
> >> >> and
> >> >> >> > > > eliminate
> >> >> >> > > > > the possibility, we could document it so that users can
> >> choose
> >> >> to
> >> >> >> do
> >> >> >> > > > weird
> >> >> >> > > > > things if they want, etc.
> >> >> >> > > > >
> >> >> >> > > > > Another thing that is usually good to think about is the
> >> >> >> expectation
> >> >> >> > > for
> >> >> >> > > > > `equals` and `hashCode`. What if subclasses implement
> them to
> >> >> have
> >> >> >> > > value
> >> >> >> > > > > semantics instead of identity semantics. Is that OK or
> would
> >> it
> >> >> >> break
> >> >> >> > > > > things?
> >> >> >> > > > >
> >> >> >> > > > > Designing for implementation inheritance is generally
> complex
> >> >> >> > although
> >> >> >> > > > for
> >> >> >> > > > > simple "record" like classes, it can be easier by
> following a
> >> >> few
> >> >> >> > > > > guidelines.
> >> >> >> > > > >
> >> >> >> > > > > Ismael
> >> >> >> > > > >
> >> >> >> > > >
> >> >> >> > >
> >> >> >> >
> >> >> >> >
> >> >> >> >
> >> >> >> > --
> >> >> >> > Nacho - Ignacio Solis - isolis@igso.net
> >> >> >> >
> >> >> >>
> >> >> >
> >> >> >
> >> >> >
> >> >> > --
> >> >> > Nacho - Ignacio Solis - isolis@igso.net
> >> >> >
> >> >>
> >> >>
> >> >>
> >> >> --
> >> >> Nacho - Ignacio Solis - isolis@igso.net
> >> >>
> >>
> >>
> >>
> >> --
> >> Gwen Shapira
> >> Product Manager | Confluent
> >> 650.450.2760 | @gwenshap
> >> Follow us: Twitter | blog
> >>
>
--
-- Guozhang