Java1.6应用迁移至Java11时gfe.jar中SDLParser异常问题咨询

gfe.jar版本说明 #

de.vcs.spc.ett包属于企业私有组件，未在公开开源仓库及公共资源站点发布，无公开可获取的Java11适配更新版本。你需要联系该组件的开发厂商VCS，或你所在项目的历史维护人员，获取对应Java11编译的适配版本。

兼容修复方案 #

你当前相同代码、相同依赖在Linux环境可正常运行，说明报错不是组件本身逻辑问题，是Java11不同环境下的XML解析默认配置、类加载逻辑差异导致，可通过以下方式修复：

• 补全Java11缺失的XML相关模块启动参数，确保XML核心能力兼容旧版实现：
  启动时添加参数：

  --add-modules java.xml,java.xml.bind
  

  同时确认项目中引入的JAXB实现包（jaxb-api、jaxb-impl、jaxb-core）版本不低于2.3.3，该版本是首个完整兼容Java11的JAXB稳定版
• 统一SAX解析器实现，规避不同操作系统JDK默认实现差异：
  启动时添加参数指定SAX解析器实现为JDK内置的稳定版本：

  -Djavax.xml.parsers.SAXParserFactory=com.sun.org.apache.xerces.internal.jaxp.SAXParserFactoryImpl
  

• 调整classpath加载顺序：
  Java11的类加载优先级和Java6存在差异，将gfe.jar放在classpath的最靠前位置，确保组件内部的类型注册逻辑优先于其他XML相关依赖执行，避免类型未被注册的问题
• 反射补充注册缺失类型（无新版本时的最终兜底方案）：
  可以通过字节码反编译工具查看SDLParser类的内部逻辑，找到类型注册的存储集合或注册方法，应用启动时通过反射手动将IdentifiedBlock类型注册到对应集合中，即可绕过类型校验报错

验证方法 #

配置调整后，执行代码前先通过反射获取SDLParser中所有已注册的类型列表，打印确认IdentifiedBlock已存在于注册列表中，再执行原有逻辑即可验证修复效果

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