hi Matthias Thanks for offering this approach. I had considered proposing it before. My concern was the new/deprecated config is used by client, so it could cause a bunch of warning messages by default. Also, users have to add the new/deprecated config to each client properties if they want to eliminate the noise.
However, as Juma mentioned that the approach was applied by another KIP before, so +1 to the new/deprecated config. To Ken Could you please update the KIP to include the new config? Additionally, please add the other discussed approaches to the “rejected” section. Best, Chia-Ping > Ismael Juma <m...@ismaeljuma.com.invalid> 於 2025年4月22日 上午11:03 寫道： > > 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 >> >>
