[
https://issues.apache.org/jira/browse/KAFKA-7267?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matthias J. Sax updated KAFKA-7267:
-----------------------------------
Component/s: streams
> 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
> Components: streams
> Affects Versions: 2.0.0
> Reporter: John Roesler
> Priority: Minor
> Labels: scala
>
> 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)
