[jira] [Created] (KAFKA-7267) KafkaStreams Scala DSL process method should accept a ProcessorSupplier

["John Roesler (JIRA)" <ji...@apache.org>]

John Roesler created KAFKA-7267:
-----------------------------------

             Summary: KafkaStreams Scala DSL process method should accept a ProcessorSupplier
                 Key: KAFKA-7267
                 URL: https://issues.apache.org/jira/browse/KAFKA-7267
             Project: Kafka
          Issue Type: Improvement
            Reporter: John Roesler


scala.KafkaStreams#process currently expects a ()=>Processor, which is semantically equivalent to a ProcessorSupplier, but it's the only such method to do so.

All the similar methods in the Scala DSL take a Supplier like their Java counterparts.

Note that on Scala 2.12+, SAM conversion allows callers to pass either a function or a supplier when the parameter is a ProcessorSupplier. (But if the parameter is a function, you must pass a function)

But on scala 2.11-, callers will have to pass a function if the parameter is a function and a supplier if the parameter is a supplier. This means that currently, 2.11 users are confronted with an api that demands they construct suppliers for all the methods *except* process, which demands a function.

Mitigating factor: we have some implicits available to convert a Function0 to a supplier, and we could add an implicit from ProcessorSupplier to Function0 to smooth over the API.

 

What to do about it?

We could just change the existing method to take a ProcessorSupplier instead.
 * 2.12+ users would not notice a difference during compilation, as SAM conversion would kick in. However, if they just swap in the new jar without recompiling, I think they'd get a MethodDefNotFound error.
 * 2.11- users would not be able to compile their existing code. They'd have to swap their function out for a ProcessorSupplier or pull the implicit conversion into scope.
 * Note that we can delay this action until we drop 2.11 support, and we would break no one.

We could deprecate the existing method and add a new one taking a ProcessorSupplier.
 * All scala users would be able to compile their existing code and also swap in the new version at runtime.
 * Anyone explicitly passing a function would get a deprecation warning, though, regardless of SAM conversion or implicit conversion, since neither conversion won't kick in if there's actually a method overload expecting a function. This would drive everyone to explicitly create a supplier (unnecessarily)

We could leave the existing method without deprecating it and add a new one taking a ProcessorSupplier.
 * All scala users would be able to compile their existing code and also swap in the new version at runtime.
 * There would be no unfortunate deprecation warnings.
 * The interface would list two process methods, which is untidy.
 * Once we drop 2.11 support, we would just drop the function variant.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)