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
