@dguy @viktorsomogyi here's the motivation: Kafka Streams cannot inference types and hence auto-register serdes for all intermediate data due to type erasure in Java. We think this is a minor issue in practice since for production code, most likely the data format is not primitive types, but schema-oriented like JSON / Avro, etc. In this case, a single registered serde class at config time should be sufficient to serde all types of data.
But users have been pointed out, quoted below: ``` ... if you are using a lot of POJO(Plain old java object) in your application, you have the added task of specifying how to serialize them in order to pass them down the pipeline, Avro schema or not. Although understandable, it adds an extra dimension of complexity that I'm not sure is always worth it in business logic heavy applications. ``` This complexity is illustrated in the `PageViewTypedDemo.java` example code: comparing with `PageViewUntypedDemo.java` it requires a serde class for each POJO typed class, and also users have to specify them during the topology via `Consumed`, `Serialized`, etc. The idea here, is to define a parent interface that returns the right serde. Then, you can set the default serde to it that extracts the right serde dynamically. As you can see the diff, although the key types are still primitive, hence enforcing users to specify different serdes whenever it changes, the value serde is always `JSONSerde`. So imagine the key type is not primitive but also JSON typed, we can actually save all the serde specifications but just specify it via config. @vvcephei a qq for you: this implementation seems be relying on `objectMapper#convertValue` in JSON, so I'm wondering if it can be generalized for any serde types, like Avro, Protobuf, Thrift etc for POJO classes? [ Full content available at: https://github.com/apache/kafka/pull/5590 ] This message was relayed via gitbox.apache.org for [email protected]
