Hi Chia-Ping, An "enable unreleased behavior" flag is an interesting idea; basically a feature flag. The main benefit (coarsely grained) is also its biggest weakness. I'm not really sure the target audience that would enable it.
Thanks, Kirk On Mon, Apr 14, 2025, at 9:39 PM, Chia-Ping Tsai wrote: > hi Colin > > Adding the config is a cool idea. However, the config will force us to > maintain both behaviors in 5.0. Additionally, we need a complete deprecation > cycle to remove the config. > > Maybe another alternative is to introduce a flag called > “enable.unrelased.behavior”, allowing users to “test” the new behavior > belonging to next major release. The default value is always false, and we > don’t need to deprecate it even if there is no new behavior. > > The benefit from “enable.unrelased.behavior” is we don’t need to maintain > both behaviors in 5.0. Additionally, the new config can serve for other > similar behavior changes. > > Best, > Chia-Ping > > > > Colin McCabe <cmcc...@apache.org> 於 2025年4月15日 凌晨4:12 寫道： > > > > 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 >
