[ https://issues.apache.org/jira/browse/KAFKA-7654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16693737#comment-16693737 ]
Matthias J. Sax commented on KAFKA-7654: ---------------------------------------- {quote}This can be achieved by having 2 different APIs (using the fluent style), while still retaining the possibility of passing only what's really needed. {quote} Not sure if I see how this would work? {quote}I agree, same type, but not same instance (i.e format). {quote} Technically possible, but I cannot think of a use case for which it would be necessary to use a different format? {quote}So you need to remember that some of that casting is ultimately going to happen and defensively guard against such incorrect casts. This leaks to the API in unfortunate ways. I would suggest to remove the default serdes. {quote} It a Java limitation that we loose type safety for default Serdes... Not sure though, if we should remove them. They are useful if for example, all you data is always in AVRO or JSON. For this case, you don't need to specify any Serdes on the operators at all. I also don't see, why it "leaks to the API" – cast are only required in internal classed. User facing public DSL API does not require any casts (or do I miss something?). I also want to add, that Kafka Streams come with the Processor API that is inherently not type-safe at all (for various reasons). Thus, the internal runtime, is forced to used casts anyway (unfortunately). {quote}In this specific case, the serializers shouldn't be optional, but I think I understand your point, you want a convenient API that's easy to navigate. {quote} They are optional, because you can specify them as default serdes in the config. About your suggestion. IMHO, it has the disadvantage that it introduces two classes that (from a business logic point of view) are the same thing. If a KStream knows its Serde or only knows its deserializer seems to be a runtime detail, but nothing a user should see in the API from my point of view. Thoughts? > Relax requirements on serializing-only methods. > ----------------------------------------------- > > Key: KAFKA-7654 > URL: https://issues.apache.org/jira/browse/KAFKA-7654 > Project: Kafka > Issue Type: Improvement > Components: streams > Reporter: Bruno Bieth > Priority: Major > > Methods such as KStream#to shouldn't require a Produced as only the > serializing part is ever used. -- This message was sent by Atlassian JIRA (v7.6.3#76005)