idea: check proper use of declaration-site type variance

[vlsi]

See:

• @In/@Out annotations for declaration-site variance -- kind of jspecify/jspecify#72

Currently, Java requires use-site type variance, so if someone has Function<IN, OUT> method parameter, it should rather be Function<? super IN, ? extends OUT>.

Unfortunately, it is not easy to notice that ? super and ? extends is missing, so it would be nice if there was a tool that could detect missing variance and suggest adding it.

The list of well-known classes could be hard-coded within ErrorProne: Function, Predicate, BiFunction, Consumer, Supplier, and so on.

Here a recent case:

• Make nestable condition factory accept conditions on super types assertj/assertj#2905

WDYT?

See also:

• Discussion in OpenRewrite: idea: check and fix use of declaration-site type variance openrewrite/rewrite#2621
• Discussion in forbidden-apis: idea: check proper use of declaration-site type variance policeman-tools/forbidden-apis#216

/cc @Stephan202

[kevinb9n]

+1 there is a well-known set of known-co(ntra)variant types and, at least for public methods, skipping the wildcard is virtually never okay.

An exception could be made for Predicate<Object>, but ironically, adopting JSpecify-type nullness analysis messes that one up! (You do need Predicate<? super Object> sometimes, since Object is no longer the top type, @Nullable Object is).

[graememorgan]

I really like this idea. Perhaps we'd want to exempt private method arguments for the sake of noise.