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
