Hi, Thanks for the KIP. Sorting this out in 3.8.0 would be really nice as it would allow us to migrate this tool in 4.0.0. We're unfortunately past the KIP deadline but maybe this is small enough to have an exception.
I'm wondering whether we need to introduce a new Decoder interface and instead if we could reuse Deserializer. We could deprecate the key-decoder-class and value-decoder-class flags and introduce new flags like key-deserializer-class and value-deserializer-class. One benefit is that we already have many existing deserializer implementations. WDYT? One issue I also noted is that some of the existing Decoder implementations (StringDecoder for example) can accept configurations but currently DumpLogSegments does not provide a way to pass any configurations, it creates an empty VerifiableProperties object each time it instantiates a Decoder instance. If we were to use Deserializer we would also need a way to provide configurations. Thanks, Mickael On Wed, May 22, 2024 at 4:12 PM Chia-Ping Tsai <chia7...@apache.org> wrote: > > Dear all, > > We know that 3.8.0 KIP is already frozen, but this is a small KIP and we > need to ship it to 3.8.0 so as to remove the deprecated scala interface from > 4.0. > > Best, > Chia-Ping > > On 2024/05/22 14:05:16 Frank Yang wrote: > > Hi team, > > > > Chia-Ping Tsai and I would like to propose KIP-1047 to migrate > > kafka.serializer.Decoder from core module (scala) to tools module (java). > > > > Feedback and comments are welcome. > > > > KIP-1047: > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-1047+Introduce+new+org.apache.kafka.tools.api.Decoder+to+replace+kafka.serializer.Decoder > > JIRA: https://issues.apache.org/jira/browse/KAFKA-16796 > > > > Thank you. > > PoAn
