[
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)
