KafkaConsumer should not be sealed

KafkaConsumer is a sealed abstract class. That serves no purpose since it is not an enumeration that gets pattern matched somewhere and it has no concrete implementations.

On the flip side, being sealed means you can’t mock it easily for testing. KafkaProducer is also abstract but not sealed.

[vlovgr]

The only gain is that we can keep adding functions to the sealed KafkaConsumer without breaking binary compatibility.

[bplommer]

I’m not sure there’s anything to split here, given the underlying API it provides access to. If admin was there, that would be one thing, but KafkaConsumer is rather focused.

Don’t think I agree. KafkaConsumer has methods for:

• consuming messages, using streams in various formats
• subscribing to / unsubscribing from topics
• manually assigning partitions
• inspecting assignments
• adjusting offsets
• inspecting offsets
• getting metrics
• getting a fiber to manually shut down the underlying consumer.

There’s a definite possibility that we’ll want to support new features that are added to Kafka in the future, and/or add higher-level functionality. Splitting out traits also lets us restrict which capabilities we pass around, so makes it easier to reason about what a program does and doesn’t do.