Hi Jiunn-Yang, Response inline...
On Wed, Mar 19, 2025, at 5:28 AM, 黃竣陽 wrote: > Hello Kirk True, > > Thanks for your comments. > > KT1: In fact, while reviewing projects on GitHub, I haven't found any that > would be affected by this change. Most developers simply retrieve the Long > value from the map and use it directly. I will continue searching to see if I > can find any cases that would be affected. I personally don't need an in-depth search to find uses of that case. It sounds like you've done a good amount of due diligence to find any uses. I'll leave it up to others to decide whether we need to press more in that area. > KT2: That is a typo, I updated that section > > KT3: AsyncKafkaConsumer also checks these return values, so I have included > AsyncKafkaConsumer in this KIP as well. Great. Thanks! Kirk > > Best Regards, > Jiunn-Yang > > > Kirk True <k...@kirktrue.pro> 於 2025年3月18日 上午9:13 寫道： > > > > 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 > >
