Description
KIP-478: https://cwiki.apache.org/confluence/display/KAFKA/KIP-478+-+Strongly+typed+Processor+API
Presently, it's very difficult to have confidence when adding to or modifying processors in the DSL. There's a lot of raw types, duck-typing, and casting that contribute to this problem.
The root, though, is that the generic types on `Processor<K,V>` refer only to the input key and value types. No information is captured or verified about what the output types of a processor are. For example, this leads to widespread confusion in the code base about whether a processor produces `V`s or `Change<V>`s. The type system actually makes matters worse, since we use casts to make the processors conform to declared types that are in fact wrong, but are never checked due to erasure.
We can start to make some headway on this tech debt by adding some types to the ProcessorContext that bound the `<K,V>` that may be passed to `context.forward`. Then, we can build on this by fully specifying the input and output types of the Processors, which in turn would let us eliminate the majority of unchecked casts in the DSL operators.
I'm not sure whether adding these generic types to the existing ProcessorContext and Processor interfaces, which would also affect the PAPI has any utility, or whether we should make this purely an internal change by introducing GenericProcessorContext and GenericProcessor peer interfaces for the DSL to use.
Attachments
Issue Links
- is duplicated by
-
KAFKA-12532 Migrate Stream operators to new Processor API
-
- Resolved
-
- relates to
-
-
- Resolved
-
- links to