不使用 JRE 的 XML 实用程序的 Java 中的 XSLT

Posted 2023-02-26

【中文标题】不使用 JRE 的 XML 实用程序的 Java 中的 XSLT

【英文标题】：XSLT in java without using the JRE's XML utils

【发布时间】：2019-05-17 10:31:29

【问题描述】：

看起来 JDK 提供了自己的 apache xalan 的阴影版本。

我在使用 XSLT 生成 XML 时发现了一个错误（错误是一个新行，并且在某些 cdata 部分中添加了缩进）。这在未发布的 jdk12 中已修复。我想避免这种情况，我必须等待 oracle 解决问题以及升级使用的 JRE。

我研究了通过 maven 将 xalan 作为依赖项。这确实有效，似乎可以解决问题，但是 xalan 的最后一次更新似乎是 2014 年 7 月 24 日。距离上一次更新已经超过 4 年了。

我希望能够依赖 xalan 或其他支持 XSLT 的东西，而不需要来自 JRE 的依赖。

oracle 是否为独立于 apache 的 JRE 维护自己的 xalan 版本？ 为什么 maven 上的 xalan 自 2014 年 7 月以来一直没有更新？ 依赖 xalan 会导致各种问题吗？我确实在Dealing with "Xerces hell" in Java/Maven? 中看到排除了 xml-apis 以尝试避免一些问题。 使用不太可能被 JVM 使用的不同 XML 库会更好吗？什么是值得研究的图书馆。

【问题讨论】：

Java 12 将于 3 月发布。等到那时可能会更容易。

#4：查看同样支持 XSLT 3.0 的 Saxon，这些问题的答案如下：How to use XSLT 3.0 from a Java application? 和 How can I use XSLT 2.0 and XSLT 3.0 in Java?

【参考方案1】：

尽我所能回答（但您的一些问题需要内部知识）：

1234563 /p>

Xalan 尚未修改，因为没有人在处理它。它最初的赞助商是 IBM 和 Sun（它部分源自 IBM 的 LotusXSL，部分源自 Sun 的 XSLTC）。 Sun的开发人员在被甲骨文收购后离开； IBM 将其投资转移到商业 Websphere XSLT 2.0 处理器和 Datapower 引擎上。所以 Xalan 仍然是 XSLT 1.0 处理器，这意味着规范在 19 年内没有改变，代码也相应变得稳定，因此几乎不需要修复 bug。需要比 Xalan 提供的更多功能的用户通常会转向 Saxon，除非他们的预算足以让 Websphere 或 Datapower 负担得起。

不，很有可能让应用程序使用 Apache 版本的 Xalan 和/或 Xerces 而不会遇到任何技术问题。

（我对此感兴趣）迁移到 Saxon 可为您提供 XSLT 2.0 和 XSLT 3.0 的所有功能和生产力优势；产品得到持续开发和维护并得到很好的支持；在某些情况下，您可能会看到性能大幅提升；多年来，在诊断、可配置性和仪器仪表等领域取得了很多进步。但好处与代码是否也在JVM中使用无关。

【讨论】：

感谢您的回复！ Saxon 看起来很整洁，我确实注意到，当我依赖它时，它会立即与

这是一个合理的问题。如果您的应用程序依赖于TransformerFactory.newInstance()，则表示它已准备好使用在类路径中找到的任何 XSLT 引擎，如果 XSLT 尚未编写和测试可移植性，这是一件危险的事情。

我想至少现在我可以控制使用的 XML 解析器，如果出现问题，即使我需要自己修复，我也可能有更好的机会修复它.希望直接将代码导入 Eclipse。