Specifically, the culprit is `? extends K1` and `? extends V1`. The type system won't go so far as to assume that if I return, say, Integer-valued results, then `V1` must be `Integer`. Because I didn't say I would _return_ a `V1`, just that whatever I return will _extend_ `V1`, and I never said what `V1` would actually be.
Unfortunately, it gets even less sensible from here... To solve that problem, it should be sufficient to fix V1 and K1, like this: `.<Integer, Integer>transform(...)`. But _that_ fails with a message that `Transformer<Windowed<String>, Long, KeyValue<Integer, Integer>>` can't be converted to `Transformer<Windowed<String>, Long, KeyValue<? extends Integer, ? extends Integer>>`. I thought maybe it doesn't consider `Integer` to extend `Integer`, but `.<Number, Number>transform(...)` also doesn't work. I think what we're dealing with is just the insufficiency of Java's type system. I have heard several times that they deliberately stopped short of fully implementing the type system in exchange for performance, so there are some true type statements that nevertheless don't compile. Maybe this is one of them. I think that we'd rather keep the ability to use lambda substitution for the supplier and give up the "maximum flexibility" on the return values for K1 and V1. Maybe you can just replace `? extends K1` with `K1` (and the same for `V1`) and re-attempt the experiments I went though before so we know what we're giving up? [ Full content available at: https://github.com/apache/kafka/pull/5273 ] This message was relayed via gitbox.apache.org for [email protected]
