You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@kafka.apache.org by "John Roesler (JIRA)" <ji...@apache.org> on 2019/05/22 20:18:00 UTC

[jira] [Created] (KAFKA-8410) Strengthen the types of Processors, at least in the DSL, maybe in the PAPI as well

John Roesler created KAFKA-8410:
-----------------------------------

             Summary: Strengthen the types of Processors, at least in the DSL, maybe in the PAPI as well
                 Key: KAFKA-8410
                 URL: https://issues.apache.org/jira/browse/KAFKA-8410
             Project: Kafka
          Issue Type: Improvement
          Components: streams
            Reporter: John Roesler


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.



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