JDK 1.6和Xerces？

Question

在我当前的项目中，我们的目标是JDK 1.6 Runtime环境。对于传统rasons，Xerces JAR文件捆绑在应用程序中。

不再需要这些吗？ JDK（有一段时间）在JDK中捆绑了XML解析库吗？

Answer 1

这些XML服务使用所谓的“服务提供商”机制插入应用程序环境。

它的工作原理如下：

1. 它尝试查找应该使用的精确指向工厂类的系统属性。例如。 -Djavax.xml.parsers.SAXParserFactory=<some class>。
2. 如果未找到系统属性FactoryFinder在特殊属性文件中查找属性。例如${java.home}/lib/jaxp.properties。
3. 如果找不到文件属性，FactoryFinder会在类路径META-INF/services/<some service>中查找服务描述，例如META-INF/services/javax.xml.parsers.SAXParserFactory。 它是一个应包含工厂类名称的文件，例如org.apache.xerces.jaxp.SAXParserFactoryImpl。
4. 如果类路径中没有此类文件，则java使用其默认工厂实现。

因此，如果你没有指向明显工厂类的系统属性，那么java会悄悄地选择合适的实现。

Answer 2

自{1.4}将JAXP添加到JRE以来，没有必要捆绑XML解析器。您应该使用JAXP而不是直接调用Xerces。在内部，JRE捆绑并使用Xerces（使用“com.sun”前缀）。

Answer 3

JDK中的解析器是Xerces的一个分支，但它非常错误。我建议生产应用程序始终优先使用Apache版本的解析器。这些错误是罕见的，但它们是不可预测的，它们不仅仅影响在现实生活中看不到的角落情况;我发现很多情况下正在解析相当无聊的XML文档，并且将损坏的数据传递给应用程序以获取属性值。 Sun / Oracle没有表现出解决问题的兴趣。每次都使用Apache Xerces。

更新（2018年）

据我所知，JDK版本的Xerces的问题似乎已经在Java 8中得到解决，所以这个建议已经过时了。

Answer 4

认可的标准覆盖机制可以正常运行。 Djava.endorsed.dirs = path_to_folder_containing_new_library_jars将解决JDK 1.6的问题。

我已经在Thymleaf的背景下验证了上述解决方案。在某些情况下，如果您使用LEGACYHTML5模式，并且如果您使用NekoHtml解析器自动更正未关闭的html标记， Neko依赖于Xerces罐子。设置类路径并不能解决问题。

谢谢s-n-ushakov。