Status

Current state:  "Under Discussion" Subsumed by KIP-365

Discussion thread: here

Github PR: here

...

I've proposed when Kafka Stream's Scala API was not released yet to solve the serdes issue on functions that takes a materialized (count, reduce and aggregate) to just make the materialized implicit and have a default implicit in ImplicitConversions that had the serdes filled in:.

Given the following definitions:
defcount()(implicitmaterialized: Materialized[K, Long, ByteArrayKeyValueStore])
defreduce(reducer: (V, V) =>V)(implicitmaterialized: Materialized[K, V, ByteArrayKeyValueStore])
defaggregate[VR](initializer: =>VR)(aggregator: (K, V, VR) =>VR)(implicitmaterialized: Materialized[K, VR, ByteArrayKeyValueStore])

...

• Making Materialized implicit suggests that a Materialized is a context object whereas it's not.
• The user of the API will by default just not care about implicit parameters and assume that they are provided.
• The user of the API might declare it's own Materialized in an implicit val since the parameter is implicit and then be caught by other unwanted functions that also takes Materialized as implicit.
• This a long shot view but in Scala 3 giving implicits explicitly looks like:
  groupedStream.count().explicitly(Materialized.as("store-name"))
  So it's clear thathat implicits should not be used as a defaulting system.

All of that applies to Consumed and Produced too.

...

def to(extractor: TopicNameExtractor[K, V])(implicit keySerde: Serde[K], valueSerde: Serde[V])
def to(extractor: TopicNameExtractor[K, V], produced: Produced[K, V])

This way we require only the implicit Serdes if the Materialized (or Consumed, or Produced) is not given explicitly.

...