Hi Chia-Ping, Thanks for the idea, although I have some concers with it. As discussed on the jira, I think it would be a good practice to keep the current structure as I think the "headers" parameter would really be optional in our case. There are multiple ways to express this in Java, such as method overloads, the "Optional" wrapper, builders and so on. Also I think all of the serializers in the Kafka project uses the 2 parameter one and also most of the implementations I could find online (disclaimer: it was just non-representative github search). Also wouldn't it be easier just to deprecate the Serializer/Deserializer and tell users to use the ExtendedSerializer/ExtendedDeserializer? I think this would also have the same side effect and in Kafka 3.0 we could also remove the deprecated interfaces.
Cheers, Viktor On Tue, Jul 17, 2018 at 10:27 AM Chia-Ping Tsai <chia7...@apache.org> wrote: > here is my two cents. > > In order to keep the BC, SC, and correct deprecation cycle(deprecate > Serializer/Deserializer in 2.0), the solution of this issue is to introduce > a new class to replace the Serializer and Deserializer. The new class > should be a subclass of Serializer/Deserializer and it has the method > "byte[] serialize(String topic, Headers headers, T data)". Also, we have to > add default implementation of the new method to Serializer/Deserializer for > BC and SC, and Serializer/Deserializer should be marked as @deprecated. > > The benefits are 1) we can keep the BC and SC in 2.0, 2) the > Serializer/Deserializer can be removed in the future without breaking the > compatibility rule since we have deprecated them, and 3) the new kafka user > can use new Serializer/Deserializer in 2.0 and it still work in 3.0. > > The side effect is that we have to update all Public APIs and docs > referencing to the Serializer/Deserializer. However, IIRC the main usage of > Serializer/Deserializer is in Producer/Consume so we can tolerate the pain. > > On 2018/07/09 08:50:07, Viktor Somogyi <viktorsomo...@gmail.com> wrote: > > Hi folks, > > > > I've published KIP-336 which is about consolidating the > > Serializer/Deserializer interfaces. > > > > Basically the story here is when ExtendedSerializer and > > ExtendedDeserializer were added we still supported Java 7 and therefore > had > > to use compatible constructs which now seem unnecessary since we dropped > > support for Java 7. Now in this KIP I propose a way to deprecate those > > patterns: > > > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=87298242 > > > > I'd be happy to receive some feedback about the KIP I published. > > > > Cheers, > > Viktor > > >
