JDK11下XSLT XPath转换异常问题排查方向咨询
检查XSLT版本兼容性
JDK 11内置的XSLT处理器（不管是Xalan还是Oracle原生实现）对XSLT版本的支持逻辑可能和JDK 8存在差异。先查看你的XSL文件开头的版本声明，比如xsl:version="1.0"或2.0，确认JDK 11的处理器是否完全兼容该版本的语法特性。比如JDK 8中被宽松处理的某些XSLT 1.0写法，到JDK 11里可能因严格遵循规范导致行为直接改变。排查类路径冲突
Eclipse升级后，项目类路径很可能混入不同版本的XSLT相关依赖（比如Xalan、Saxon等jar包），和JDK自带的处理器产生冲突。检查项目依赖库，避免多个版本的XSLT处理器共存；也可以通过Eclipse的Run Configuration查看运行时类路径，揪出重复或不兼容的依赖。核对JDK XML相关的其他系统属性
除了你设置的三个XPath限制参数，JDK 11还调整了不少XML相关系统属性，比如jdk.xml.entityExpansionLimit、jdk.xml.maxElementDepth等。它们的默认值和JDK 8可能不同，可能触发限制或改变转换行为。可以尝试把这些参数显式设为和JDK 8一致的值，或者查阅JDK 11文档确认默认配置的变化。验证节点上下文是否一致
检查使用..的XPath表达式所在的上下文节点，在JDK 11中是否发生偏移。比如<xsl:for-each>循环、<xsl:apply-templates>或模板匹配过程中，当前节点的上下文可能因处理器实现细节不同而变化，导致..指向的父节点和预期不符。可以在XSL中添加调试输出，比如<xsl:value-of select="name(..)"/>，对比JDK 8和JDK 11中父节点的名称或内容，确认上下文是否一致。检查字符编码与XML解析差异
JDK 11的XML解析器（Xerces）对字符编码的处理更严格。比如JDK 8中能自动识别的编码，到JDK 11中可能需要显式声明。检查输入XML的编码声明，以及XSL转换时指定的输出编码，确保两个环境的编码设置一致，避免因编码问题导致节点内容解析错误，进而影响XPath结果。排查Eclipse插件的干扰
Eclipse 4.23自带的XML/XSLT相关插件（比如WTP的XML编辑器、XSLT处理器插件）可能和JDK内置处理器产生交互。尝试脱离Eclipse，直接在命令行运行XSL转换，如果此时结果正常，说明问题大概率出在Eclipse的插件配置或运行环境上——比如Eclipse的JRE配置错误，或者插件覆盖了JDK的XML处理器。确认XPath表达式的规范符合性
有些XPath表达式在JDK 8中依赖处理器的宽松实现返回了预期结果，但JDK 11严格遵循W3C规范，结果就会不同。比如当前节点是根节点时使用..，JDK 8可能返回空节点集，JDK 11的处理逻辑可能有差异；或者带命名空间的XML中，..是否正确处理了命名空间上下文。把所有使用..的XPath表达式都过一遍，确保它们的行为符合W3C XPath规范，不要依赖JDK 8的特定实现。
内容的提问来源于stack exchange，提问作者Vishal Sharnagat
