Hi, I prefer to have my code as "warning free" as possible so I was looking through some of the warnings my IDE gives about some of the Flink code I'm working on when I ran into this:
Raw use of parameterized class 'SinkFunction.Context' Apparently the interface for a SinkFunction has the method void invoke(IN value, Context context) https://github.com/apache/flink/blob/master/flink-streaming-java/src/main/java/org/apache/flink/streaming/api/functions/sink/SinkFunction.java#L51 So *Context* is used here as a normal class. Yet the actual definition (in the same file, about 15 lines below) shows interface Context<T> { which is a generic. https://github.com/apache/flink/blob/master/flink-streaming-java/src/main/java/org/apache/flink/streaming/api/functions/sink/SinkFunction.java#L66 So in all SinkFunction implementations everywhere this issues a warning in the code (also in what I'm working on). I cannot simply fix my code by adding the type parameters because that makes my code no longer implement the interface. 'invoke(IN, Context<IN>)' in 'org.apache.flink.streaming.connectors.gcp.pubsub.PubSubSink' clashes with 'invoke(IN, Context)' in 'org.apache.flink.streaming.api.functions.sink.SinkFunction'; both methods have same erasure, yet neither overrides the other I tried to simply add the extra function to the SinkFunction void invoke(IN value, Context<IN> context) which fails with 'invoke(IN, Context)' clashes with 'invoke(IN, Context<IN>)'; both methods have same erasure So they are "same enough" to clash and "different enough" to not be seen as an implementation of the interface. So as far as I can see the 'only' way to fix this is either a breaking API change and cleanly add this generic parameter everywhere OR remove it from the interface. Note that the Context<T> interface does not use the generic parameter and has the comment // Interface might be extended in the future with additional methods. I read this as future extensibility which has not been implemented (yet) and which has not been placed in all code correctly. What do you guys think of this ? I'm inclined to simply remove the generic type parameter from this interface. -- Best regards / Met vriendelijke groeten, Niels Basjes
