实现带<TIn extends T>及数组类型参数接口的变通方案

这个编译报错属于Java语法层面的硬性限制，和泛型擦除、类型逻辑无关：Java编译器在解析泛型上界声明时，不允许直接在类型变量后拼接数组声明符[]，也就是说<TIn extends TItem[]>这类写法会在语法解析阶段直接被拦截，连类型校验环节都走不到，这也是IDEA自动生成实现代码失效的原因。

以下方案均不需要修改原有Foo接口定义，不影响非数组场景的存量使用，全部能通过编译校验：

• 直接省略方法级泛型参数，利用数组固有特性实现需求
  Java数组本身是协变的，天生满足“接收子类型参数”的需求：比如String[]是Object[]的子类型，HashMap<X>[]是Map<X>[]的子类型，完全匹配你当初加<TIn extends T>约束想要的灵活性。
  实现数组版本的Foo时，不需要写<TIn extends T[]>的泛型声明，直接把encode方法参数定义为对应数组类型即可：

  // 实现Foo<TItem[]>时
  @Override
  public void encode(TItem[] array) {
    // 业务逻辑
  }
  

  针对byte[]、Boolean这类final类型的实现也用同样逻辑，直接写死参数类型即可，编译器会自动适配接口签名，不存在类型不匹配问题。
• 用类级泛型参数绕开语法解析限制
  如果为了和其他实现类的代码风格统一，必须保留方法级的泛型上界声明，可以把数组类型先绑定到类级别的泛型参数上，避免在方法泛型的extends后直接出现[]符号：

  // 多加一个类泛型参数承接数组类型，上界声明放在类层面
  public class ArrayFooImpl<TItem, TArray extends TItem[]> implements Foo<TArray> {
      @Override
      public <TIn extends TArray> void encode(TIn array) {
          // 业务逻辑，此处不会触发语法报错
      }
  
      @Override
      public TArray decode() {
          // 业务逻辑
      }
  }
  

  实际使用时因为数组类型本身没有自定义子类型，TArray永远只会是对应TItem[]类型，不会产生额外的类型适配成本。

注意：不要为了绕开这个问题修改Foo接口的原有泛型定义，否则会导致所有存量非数组场景的实现出现兼容问题。

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