Hey G, Looks like the only difference is a valueSerde parameter.
How does that prevent having to look for nulls in the consumer? E.g, I wrote a custom Serde which converts the messages (which are json strings) into a Java class using Jackson. If the json parse fails, it sends back a null. When I'm reading this stream, in my callback, how would I prevent having to check if the serialized value isn't null? On Sat, Oct 8, 2016 at 1:07 AM, Guozhang Wang <[email protected]> wrote: > Hello Ali, > > We do have corresponding overloaded functions for most of KStream / KTable > operators to avoid enforcing users to specify "null"; in these cases the > default serdes specified in the configs are then used. For example: > > <T> KTable<K, T> aggregate(Initializer<T> initializer, > Aggregator<K, V, T> adder, > Aggregator<K, V, T> subtractor, > Serde<T> aggValueSerde, > String storeName); > > /** > * .. using default serializers and deserializers. > */ > <T> KTable<K, T> aggregate(Initializer<T> initializer, > Aggregator<K, V, T> adder, > Aggregator<K, V, T> subtractor, > String storeName); > > > > Guozhang > > > On Fri, Oct 7, 2016 at 9:20 AM, Michael Noll <[email protected]> wrote: > > > Ali, the Apache Kafka project still targets Java 7, which means we can't > > use Java 8 features just yet. > > > > FYI: There's on ongoing conversation about when Kafka would move from > Java > > 7 to Java 8. > > > > On Fri, Oct 7, 2016 at 6:14 PM, Ali Akhtar <[email protected]> wrote: > > > > > Since we're using Java 8 in most cases anyway, Serdes / Serialiazers > > should > > > use options, to avoid having to deal with the lovely nulls. > > > > > > > > > -- > -- Guozhang >
