Java XML API 漫谈

在IBM的developerWorks上有几篇非常优秀的关于Java XML API的评测文章，它们是：

http://www-900.ibm.com/developerWorks/cn/xml/x-injava/index.shtml

http://www-900.ibm.com/developerWorks/cn/xml/x-injava2/index.shtml

http://www-900.ibm.com/developerWorks/cn/xml/x-databdopt/part2/index.shtml

http://www-900.ibm.com/developerWorks/cn/xml/x-databdopt/part1/index.shtml

对这几篇文章我想说的就是“吐血推荐”

Java的XML API这几篇文章该讲的都讲到了，我只想补充几点：

一、Crimson和Xerces恩仇录

Crimson来自于Sun捐赠给Apache的ProjectX项目，Xerces来自IBM捐赠给Apache的XML4J项目，结果Xerces胜出，成了Apache XML小组全力开发的XML API，而Crimon已经早就不做了，如今Xerces名满天下，到处都是在用Xerces DOM和SAX解析器，只有Sun不服气，非要在JDK1.4里面使用过时的Crimson，让人感觉像是在赌气一样，真是让人可怜又可气！不过IBM发行JDK用的XML 解析器自然是Xerces。

由于JDK的Class Loader的优先级关系，当你采用JAXP编写XML程序的时候，即使把Xerces包引入CLASSPATH，JDK还是会顽固的使用Crimson，这一点通过打开JVM的verbose参数可以观察到。不过JDK也允许你采用其它的解析器，因此我们可以通过在JRE\lib\目录下建一个jaxp.properties的文件，来替换解析器，jaxp.properties内容如下：


这样就可以使用Xerces，当然你必须还是要把Xerces包放到CLASSPATH下。

二、JAXP的姗姗来迟

Sun在XML领域总是后知后觉，等到Sun重视XML的时候，XML的API早就满天 飞了，尤其是IBM具有非常大的领先优势。不过Sun是规范的制订者，于是参考W3C的标准制订了JAXP规范。JAXP不像Xerces和Crimon那样，它只是一个spec，本身是不做任何事情的，它的作用就是提出一个统一的接口，让其它的XML API都来遵循JAXP编程，那么用JAXP写出来的程序，底层的API可以任意切换。

具体来说JAXP包括了几个工厂类，这就是JDK1.4里面的javax.xml.parsers 包，用来寻找符合DOM标准的XML API实现类的位置；此外JAXP还包括一整套interface，这就是JDK1.4里面的org.w3c.dom那几个包。工厂类负责加载DOM的实现类。那么加载的规则是什么呢？

我是通过阅读JAXP的源代码知道的，工厂类首先会根据java命令行传入的参数进行寻找，然后在根据JRE\lib\jaxp.properties中定义的实现类寻找，最后什么都找不到的话，就用Crimson。注意Crimons是由Bootstrap Class Loader来load的，如果你不通过上面两个方法来改变工厂的寻找顺序，那么铁定用Crimson了

三、 DOM解析器和DOM API

当你严格采用JAXP编程的时候，是遵循W3C的DOm标准的，那么在JAXP底层你实际上可以任意切换不同的DOM实现，例如Xerces，或者Crimon，再或者其它，切换方法就是配置jaxp.properties。因此JAXP就是一些标准接口而已。

而Xerces和Crimon也不单单是一个DOM实现那么简单，他们本身实际上也包含SAX解析器和DOM解析器。所以一个JAXP程序下面有如下层次：



只要你用JAXP编程，那么你就可以切换到Crimson上来



另外你也可以这样来做：



不过如果你的程序不安装JAXP来写，那么就没有办法切换不同的DOM实现了。

四、不是标准的dom4j和jdom

W3C的DOM标准API难用的让人想撞墙，于是有一帮人开发Java专用的XML API目的是为了便于使用，这就是jdom的由来，开发到一半的时候，另一部分人又分了出来，他们有自己的想法，于是他们就去开发dom4j，形成了今天这样两个API，至于他们之间的性能，功能之比较看看上面我推荐的文章就知道了，jdom全面惨败。

jdom 相当于上面的  JAXP接口 ＋ Xerces DOM实现部分，它本身没有解析器，它可以使用Xerces或者Crimson的解析器，就是这样：



dom4j 和jdom类似，不过他自己绑定了一个叫做Alfred2的解析器，功能不是很全，但是速度很快，当没有其它的解析器的时候，dom4j将使用Alfred2解析器，如下：



或者



你在SF上下载的dom4j.jar是不含 Alfred2解析器的，而dom4j-full.jar包含了 Alfred2解析器，在这种情况下，实际上你什么也不需要，光是一个dom4j-full.jar就全部都包括了。

因此可以看出采用dom4j/jdom编写的应用程序，已经不具备可移植性了。

五、小插曲

Sun是JAXP标准的制订者，甚至很执著的在JDK1.4里面绑定Crimson DOM实现和解析器，然后可笑的是，Sun自己的JAXM RI竟然不是用JAXP写出来的，而是dom4j，制订标准让大家遵守，自己却监守自盗，这未免太说不过去了吧！

BTW: Hibernate也用的是dom4j来读取XML配置文件，如今已经越来越多的程序纷纷采用dom4j，如果你不是那么在乎可移植性，我强烈建议你采用dom4j。

那應該可以考慮使用 dom4j 了 .... ^^

我以前也一直用JDOM的，关键是JBuilder里面自带的是JDOM。

你到SF上去下载一个dom4j-full.jar然后放到JB里面也很方便

呵呵，这不过是我的游戏之作，谢谢你的夸奖！！！

另外文章谈到了IBM和Sun的恩怨，IBM不会让发表的。

找到问题了，但是无法解决。
由于我使用了log4j的xml配置文件。log是一个静态类变量，它会提前调用org.apache.log4j.xml.DOMConfigurator的doConfigure方法，也就是说在DOMBuilderFactory查找jaxp.proerties文件之前执行。所以必须提前用System Proerties方式传入。至于为什么这样目前我还不大清楚。

不过目前有两种方法：
1、用-Djavax.xml.parsers.DocumentBuilderFactory=org.apache.xerces.jaxp.DocumentBuilderFactoryImpl -Djavax.xml.parsers.SAXParserFactory=org.apache.xerces.jaxp.SAXParserFactoryImpl传入

2、在声明log变量之前使用静态初始块代码，保证先于doConfigure方法之前设定System Properties。
代码如下：

  static
  {
    System.setProperty("javax.xml.parsers.DocumentBuilderFactory", "org.apache.xerces.jaxp.DocumentBuilderFactoryImpl");;
    System.setProperty("javax.xml.parsers.SAXParserFactory","org.apache.xerces.jaxp.SAXParserFactoryImpl");;
  }
  private static final Log log = LogFactory.getLog(CreateDocument.class);;

不知道各位在使用到log的时候是如何解决该问题的？有没有更好的办法？

如果你需要把配置文件转化为配置类或相反操作,建议你使用castor,虽然castor源码粗糙一些,但是功能上还是可以满足一般需求的.

那还不如用xstream好了....
速度暴快，还很简单

这个真的一点都没错，用过JAXP再用dom4j，你会有劫后重生的感觉。

而且用JDK1.4的JAXP，部署到TOMCAT 还要自己加一个jar，忘了叫什么，真是恶心啊，还不如直接加一个dom4j的full jar直接。

反正尽量把调用xml的地方封装好，通用性嘛，有需求再说吧，^_^

建议使用castor，但不要使用他生成程序这种方式，而是自定义mapping