Hi Jiunn-Yang, Thanks for the KIP!
I agree that this oddity should be fixed. It's a bit of a funny case, KIP-wise, in that the API signature itself isn't changing, but the documentation and behavior are. Some questions: KT1: The KIP specifically calls out "The scenarios that will be impacted" with some skeleton code. Are you able to think of any practical cases where changing the behavior negatively impacts the user? I'm struggling to think of anything the user would/could do in that case besides log the fact. KT2: It's totally minor, but I noticed in "Public Interfaces," the same method signature for beginningOffsets is listed twice. KT3: ClassicKafkaConsumer is mentioned as needing to be changed, but what about AsyncKafkaConsumer? I do remember some discussion on that when this little wrinkle was found in the new consumer implementation. Thanks, Kirk On Fri, Mar 14, 2025, at 4:30 AM, 黃竣陽 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
