Java泛型多边界擦除仅取最左边界引发重载歧义的疑问

1. 调用歧义是否由最左边界擦除规则导致 #

是，这个问题的直接诱因就是Java泛型多边界的仅擦除最左边界规则。
根据JLS的类型擦除规范，对于T extends A & B & C形式的多上界泛型，擦除后会直接使用第一个上界A作为类型的最终擦除结果，剩余上界仅在调用点做隐式类型转换处理。
你给出的两个方法擦除后签名分别为static Do whatToDo(Do)和static Done whatToDo(Done)，参数类型不同符合Java重载的要求，因此方法本身可以正常编译。但调用时传入的Doing类同时实现了Do和Done两个接口，两个方法都匹配调用条件，因此会触发歧义错误。

2. 为什么要采用仅擦除最左边界的设计 #

核心原因是两点：向下兼容、实现成本最低。

• 泛型是JDK5才引入的特性，为了兼容JDK5之前没有泛型的Class文件和运行环境，JVM层面完全不感知泛型信息，所有泛型都要擦除为普通的非泛型类型，多边界如果要保留所有类型信息需要修改JVM的方法签名、类型判定的核心逻辑，会直接打破向下兼容的承诺。
• 最左边界的规则实现最简单，运行效率最高：通常开发中会把实体类（而非接口）放在多边界的第一个位置，擦除为类类型后调用方法不需要额外的类型转换，性能和非泛型代码一致。如果要处理无序边界集合，无论是编译器的重载判定逻辑还是JVM的方法调用逻辑复杂度都会大幅提升。

3. 是否存在更优的擦除实现方案 #

存在可行的优化方案，但都会打破Java一直坚持的向后兼容性原则：

• 方案1：重载判定阶段同时校验泛型边界信息，不需要修改JVM层面的擦除规则，仅在编译器层面对多边界的泛型方法做额外校验，如果两个方法的泛型边界集合（不考虑顺序）完全一致，直接判定为重载冲突，不允许编译通过。
• 方案2：修改擦除规则，多边界擦除为所有边界的合成类型，JVM新增对多边界合成类型的支持，方法签名携带完整的边界信息。但这个方案改动太大，会导致所有旧版本的Class文件无法在新JVM上运行，完全不可行。

4. 修改为识别无序边界集合能否避免这类问题 #

完全可以。如果编译器在判断泛型方法重载合法性时，不单纯依赖擦除后的签名，还会比对泛型边界的无序集合，你示例中的两个方法会在编译阶段就直接报「方法签名重复」的错误，而不是等到调用阶段才触发歧义，从根源上避免这类本质逻辑完全一致的方法被判定为合法重载。

内容的提问来源于stack exchange，提问作者theutonium.18