Hi Ismael, Well, yes. If we care about headers only then you'd need to add a dummy implementation for the 2 parameter method as well. Although it is not ideal, we're using the Serializer interface everywhere and convert it to extended with ensureExtended(serializer) and delegate to the 2 parameter method inside the wrapper which is returned in ensureExtended. Because of backward compatibility we have to keep delegating but I could perhaps add a dummy implementation for the 2 parameter too if you and others think that would be better. In this case though we'd have an interface where all methods are default (given the improvements of KIP-331 <https://cwiki.apache.org/confluence/display/KAFKA/KIP-331+Add+default+implementation+to+close%28%29+and+configure%28%29+for+Serializer%2C+Deserializer+and+Serde>) and would have to rethink if this interface should be a @FunctionalInterface. I don't really have a context currently on how the 3 parameter method is used, most the code samples I found on github were using the 2 parameter method. I think I found one instance where the 3 parameter one was used but that delegated to the 2 param one :). Have to say though that this research is not representative. All in all I think it wouldn't hurt to provide a default implementation for the 2 param method too but then we have to give up the @FunctionalInterface annotation and we'll end up with an interface with no abstract methods but only defaults. What do you think?
Cheers, Viktor On Mon, Jul 9, 2018 at 11:02 AM Ismael Juma <ism...@juma.me.uk> wrote: > Thanks for the KIP. It would be helpful to understand the user experience > for the case where the implementor uses the headers. It seems like it would > require overriding two methods? > > Ismael > > On Mon, Jul 9, 2018 at 1:50 AM 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 > > >
