类级别泛型参数与方法级别泛型参数的混淆疑问

你的判断是对的：Comparator接口的泛型<T>和其静态方法comparing的泛型<T>完全没有关联，它们只是碰巧用了同一个字母当参数名，就像两个不同方法里的同名局部变量，各自的作用域完全独立。

代码中看起来一致的原因 #

在你给出的代码里：

Comparator<File> fileComparator = Comparator.comparing(Inner::getValue);

编译器是通过上下文推导来确定泛型参数的，和接口的泛型没有绑定：

1. 首先，变量fileComparator的类型是Comparator<File>，这意味着comparing方法返回的Comparator<T>里的方法级泛型T必须是File。
2. 然后看方法参数Inner::getValue，这个方法接受File类型参数、返回String类型。而comparing方法的keyExtractor参数是Function<? super T, ? extends U>，这里T已经被推导为File，U则被推导为String（String实现了Comparable<String>，满足U extends Comparable<? super U>的约束）。

换个例子验证独立性 #

如果我们把静态方法的泛型参数名改成X，代码依然能正常编译：

// 修改后的comparing方法签名
public static <X, U extends Comparable<? super U>> Comparator<X> comparing(
        Function<? super X, ? extends U> keyExtractor)

此时Comparator<File> fileComparator = Comparator.comparing(Inner::getValue);还是能正常运行，因为编译器推导的是X=File，和接口的泛型参数（此时接口的T是File）只是结果相同，本质上是两个完全独立的泛型参数。

再比如创建Comparator<Integer>：

Comparator<Integer> intComparator = Comparator.comparing(Inner::getValue2);

这里方法级的泛型T是Integer，接口的泛型T也是Integer，这依然是推导的结果，不是两者有关联的证明。

核心结论 #

• 接口的泛型参数作用域仅覆盖接口的非静态成员（静态成员不属于实例，所以接口静态方法无法使用接口的泛型参数）。
• 静态方法的泛型参数作用域仅限于该方法本身，和接口的泛型参数没有任何绑定关系。
• 代码中两者看起来一致，只是编译器根据上下文和方法参数推导后，结果恰好相同而已。

内容的提问来源于stack exchange，提问作者Tom