That's right. Similar approach: https://lists.apache.org/thread/3fxqdsosm3z7xp4rr8db2qmyg5vd0v1b
Ismael On Mon, Apr 21, 2025, 7:43 PM Matthias J. Sax <mj...@apache.org> wrote: > I don't think we would need a second deprecation cycle. > > Instead, we could add this new config, and deprecate it right away. This > way, we can change the default behavior and remove the config both with > 5.0. > > I guess the core question is really, do we want to enable the old or new > behavior by default? From a backward compatibility POV, we would need to > keep the old behavior as default IMHO. > > If we can agree to this, the way forward might be: > > - keep the old behavior as default > - add a config that allows to enable the new behavior > - if use don't enable the new behavior, log a WARN telling them that > they need to migrate their code before 5.0 and encourage them to enable > the new behavior right away > - deprecate the new config right away > - remove the config and old behavior in 5.0 > > > I admit, that adding a new config, and deprecating it, plus telling > users "please use this new/deprecated config", is a little bit awkward > -- but it seems to be still the overall best way forward IMHO? > > > > -Matthias > > On 4/17/25 8:16 PM, Chia-Ping Tsai wrote: > > hi Kirk > > > > “coarsely grained” is a good point. We need to list all behaviors > impacted by the config - no matter which new config we adopted. > > > > Maybe we can add the flag to xxxOption? The benefit is users can > explicitly see “which” APIs are impacted. The downside is the number of > deprecated methods in 5.0 is increased > > > > Best, > > Chia-Ping > > > >> Kirk True <k...@kirktrue.pro> 於 2025年4月18日 清晨7:16 寫道： > >> > >> Hi Colin, > >> > >> If so, is 5.0 the earliest this 'allow.nulls.in.consumer' configuration > can be changed and marked as deprecated? And if that holds, is 6.0 the > earliest it can be removed? > >> > >> Thanks, > >> Kirk > >> > >>> On Mon, Apr 14, 2025, at 1:10 PM, Colin McCabe wrote: > >>> I would suggest adding a configuration key which controls whether the > null values are added. That configuration key can default to true in 4.x > and false in 5.x. This will give people a chance to test the new behavior > before 5.x. > >>> best, > >>> Colin > >>>> On Fri, Mar 14, 2025, at 04:30, 黃竣陽 wrote: > >>>> Hello everyone, > >>>> I would like to start a discussion on KIP-1140: Avoid to return null > >>>> value in Map from public api of consumer > >>>> <https://cwiki.apache.org/confluence/x/mIuMEw> > >>>> This proposal aims to improve the Kafka consumer API by ensuring that > >>>> the Map it returns contains only non-null values, > >>>> aligning with the design philosophy of Java collections. This change > >>>> provides significantly more benefits than drawbacks, > >>>> enhancing API consistency and usability while reducing errors caused > by > >>>> developer misuse. > >>>> Best Regards, > >>>> Jiunn-Yang > >
