为什么Java编译器需要看似无用的包装函数完成泛型边界类型检查？

class Test {
  static void foo(Class<?> clazz) {
    baz(clazz);
//    bar(clazz, clazz);    // 该行代码会编译报错
  }
  static <T> void bar(Class<T> type, Class<? extends T> subtype) {}

  static <T> void baz(Class<T> clazz) {
    bar(clazz, clazz);
  }
}

编译行为差异的核心原因 #

• 首先看foo方法里直接调用bar的场景：foo的入参Class<?>是无界通配符类型，Java编译器处理通配符时，每次对?的独立解析都会生成互不关联的未知捕获类型。也就是说调用bar(clazz, clazz)时，编译器会把第一个参数的?和第二个参数的?识别为两个完全无关的类型，自然无法满足第二个参数必须是第一个参数类型子类的约束，直接触发编译错误。
• 再看baz方法封装调用的场景：baz是带明确类型参数<T>的泛型方法，当foo把Class<?>传入baz时，编译器会做一次通配符捕获，把这个?对应的未知类型绑定到baz的类型参数T上，整个baz作用域内T都是同一个确定的捕获类型。此时调用bar(clazz, clazz)，两个入参的类型都是Class<T>，第二个参数天然符合Class<? extends T>的约束，自然可以正常编译。

是设计缺陷还是刻意决策？ #

这是经过严谨考量的设计决策，并非类型系统缺陷：

Java的通配符捕获规则是为了在支持泛型协变、逆变灵活性的同时，从编译层面保证类型安全。如果默认允许同一个通配符变量的多次引用自动识别为同一类型，反而会导致大量隐性类型安全问题：比如方法接收多个独立的Class<?>入参时，编译器如果默认判定它们的通配符是同一类型，就会放跑很多本应拦截的类型不匹配错误。
这种通过一层泛型方法封装来统一绑定通配符捕获类型的写法，本身就是Java泛型规范中明确推荐的通配符处理模式，属于专门设计的能力。

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