JDK8迁移至JDK11后ESAPI2.5.2.0报XMLGregorianCalendarImpl无效类异常

针对你遇到的JDK11迁移后ESAPI与OpenJDK的XMLGregorianCalendarImpl类冲突问题，提供以下几种可行解决方案：

1. 调整类加载优先级，让xercesImpl优先加载 #

JDK默认的双亲委派模型会优先加载JDK自带的类，但可以通过以下方式调整：

• 命令行启动参数：使用-Xbootclasspath/a:参数将ESAPI依赖的xercesImpl jar包追加到启动类路径，这样JVM会优先加载该jar中的类。示例命令：

  java -Xbootclasspath/a:xercesImpl-2.12.1.jar -jar your-application.jar
  

  注意替换为ESAPI 2.5.2.0实际依赖的xercesImpl版本（通常是2.12.1）。
• 应用服务器配置：如果是Tomcat这类服务器，修改META-INF/context.xml，添加<Loader delegate="false"/>，关闭类加载委派机制，然后将xercesImpl jar放到WEB-INF/lib下，这样应用类加载器会优先加载自身库中的类，而非JDK自带的实现。

2. 配置ESAPI使用JDK原生XML实现 #

ESAPI支持切换XML解析器实现，无需依赖xercesImpl：

• 修改ESAPI配置文件ESAPI.properties，找到ESAPI.XMLFactory配置项，将其值改为：

  ESAPI.XMLFactory=org.owasp.esapi.reference.JavaXMLFactory
  

  这个实现会直接使用JDK原生的XML相关类，避免引入xercesImpl依赖。
• 在构建工具中排除xercesImpl依赖，以Maven为例：

  <dependency>
      <groupId>org.owasp.esapi</groupId>
      <artifactId>esapi</artifactId>
      <version>2.5.2.0</version>
      <exclusions>
          <exclusion>
              <groupId>xerces</groupId>
              <artifactId>xercesImpl</artifactId>
          </exclusion>
      </exclusions>
  </dependency>
  

  这样既消除了类冲突，也不会触发ClassNotFoundException。

3. 避免直接引用具体实现类 #

如果问题源于序列化/反序列化环节，确保代码中只使用javax.xml.datatype.XMLGregorianCalendar接口，而非直接引用XMLGregorianCalendarImpl实现类。这样无论底层是JDK还是xerces的实现，都能通过接口进行操作，避免序列化时绑定到特定实现类导致的版本冲突。

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