[jira] [Comment Edited] (KAFKA-7654) Relax requirements on serializing-only methods.

["Bruno Bieth (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/KAFKA-7654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16695199#comment-16695199 ] 

Bruno Bieth edited comment on KAFKA-7654 at 11/21/18 8:35 PM:
--------------------------------------------------------------

[~mjsax] Thanks, I might end up writing a KIP if there is some support.

[~guozhang] Thanks for your thoughts as well! You make good points but I think there is some confusion about circe. Circe serializers/deserializers (called Encoder/Decoder) are built at compile-time rather than at runtime like Avro/Jackson. Therefore you simply cannot define a generic circe-based Serde. This is a _very_ good thing IMO.

I think we agree on 1) and 2) but about 3) what are the benefits of having a global serde? As far as I can see it's about not doing `builder.stream(jacksonSerde)`.
You could have for instance a `GenericSerde` (as opposed to a `Serde<T>`) and a `builder#stream(GenericSerde): KStreamGeneric` which will carry your GenericSerde throughout all the KStream operations. It's a few more classes but nothing too dramatic.



was (Author: backuitist):
[~mjsax] Thanks, I might end up writing a KIP if there is some support.

[~guozhang] Thanks for your thoughts as well! You make good points but I think there is some confusion about circe. Circe serializers/deserializers (called Encoder/Decoder) are built at compile-time rather than at runtime like Avro/Jackson. Therefore you simply cannot define a generic circe-based Serde. This is a _very_ good thing IMO.

I think we agree on 1) and 2) but about 3) what are the benefits of having a global serde? As far as I can see it's about not doing `builder.stream(jacksonSerde)`.
You could have for instance a `GenericSerde` (as opposed to a `Serde<T>`) and a `builder#stream(GenericSerde): KStreamGeneric` which will carry your GenericSerde throughout all the KStream operations. It's a few more classes but nothing too dramatic.

[~mjsax] If people stumble over the Java fluent interface then they should probably not do distributed stream processing ;) I mean, come on, there are far more complex things in the lib than that, it's like "no we cannot put the safety on this machine gun because some people struggle with it" ;) 
And we're not talking about crazy fluent interface (like https://github.com/jOOQ/jOOQ/tree/master/jOOQ/src/main/java/org/jooq ).
So basically I agree in general about complexity and finding a threshold but in that case I think it's fine. Of course I'm just a voice too :)

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