Tomcat9源码Ant构建报类型不匹配错误（Eclipse编译通过）排查

这个问题本质是两套编译环境的类加载规则不统一 + 项目中存在简单名相同的Certificate类冲突，和你编写的代码逻辑本身没有关系：

• 你代码里的Collection<Certificate>，在不同环境下被解析成了完全不同的类：
  • Eclipse能正常编译，是因为它内置的ECJ编译器在类解析时，会自动匹配和方法返回值兼容的类型——这里匹配到的是JDK自带的java.security.cert.Certificate，它是X509Certificate的父接口，PEMFile.getCertificates()返回的ArrayList<X509Certificate>天然满足泛型兼容要求，自然不会报错。
  • Ant构建时报错，是因为它调用的JDK原生javac编译器完全不会做兼容性兜底，严格按照build.xml里配置的classpath顺序，找到哪个Certificate类就用哪个。这时候如果类路径上排在JDK标准库前面的是Tomcat源码包下的自定义同名Certificate类（这个类和X509Certificate没有任何继承实现关系），就会直接抛出cannot convert from ArrayList<X509Certificate> to Collection<Certificate>的类型不匹配错误。
• 额外的触发点：Eclipse的自动导入、增量编译逻辑会优先选择能通过编译的类引用，而javac只认classpath顺序，不会主动帮你选兼容的类，最终就出现了同一个代码片段在两个环境下编译结果完全割裂的现象。

• 直接在Ant的<javac>任务里加verbose="true"参数，打开详细编译日志，顺着类加载记录找编译时实际引用的Certificate类的全路径，确认是不是错加载了非JDK路径的自定义类。
• 对比两边的类路径优先级：看Eclipse项目配置里，JRE系统库是不是排在项目源码目录的前面；再看build.xml里javac任务的classpath配置，是不是把项目源码目录、第三方依赖包放到了JDK标准库的前面。
• 翻一下项目源码目录，看是不是不小心创建了和JDK标准库结构完全一致的冗余类，比如java/security/cert/Certificate.java这种文件，这种文件会被Ant优先编入编译输出，直接替换掉JDK里的对应类。

• 最一劳永逸的改法：把代码里用到的Certificate直接写全限定名，改成Collection<java.security.cert.Certificate> chain = new ArrayList<>(certificateFile.getCertificates());，从根源上堵死编译器错选同名类的可能。
• 调整Ant的classpath加载顺序：在build.xml的javac配置里，把JDK标准类库的路径挪到classpath的最前面，保证标准库的类优先级高于项目源码、依赖包。
• 删掉项目里冗余的重名类：把那些和JDK类完全同名的自定义实现删掉，从代码层面消除冲突来源。
• 对齐两边的类引用：手动把代码里的import语句改成JDK的java.security.cert.Certificate，不要完全依赖Eclipse的自动导入选类逻辑，避免不同环境下的解析偏差。

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