Hello, Thank for the feedback. I will address this new/deprecated mechanism in the updated version of the KIP.
Best Regards, Jiunn-Yang > Chia-Ping Tsai <chia7...@gmail.com> 於 2025年4月22日 中午12:58 寫道： > > 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 >>> >>>
