概述：
Jdom是用Java语言读、写、操作XML的新API函数。Jason Hunter 和 Brett McLaughlin公开发布了它的测试版本。在直觉、简单和高效的前提下，这些API函数被最大限度的优化。在接下来的篇幅里，Hunter 和 McLaughlin介绍怎么用Jdom去读写一个已经存在的XML文档。
Jdom是一个开源的api，它以直接易懂的方式向java程序员描述XML文档和文档的内容。就象名字揭示的那样，Jdom是为java优化的。为使用XML文档提供一个低消耗的方法。Jdom的使用者可以不必掌握太多的XML的知识就可以完成想要的操作。
Jdom可以和已有的XML技术如Simple API for XML (SAX)和 Document Object Model (DOM)相互协作.然而，它并不是简单的从这些api中提取出一些。Jdom从这些已存在的技术中吸收了好的方面，自己建立了一套新的类和接口，用一个Jdom用户的话来说就是：“这些接口是我从一开始阅读org.w3c.dom就期待的”；Jdom可以读入SAX或是DOM的内容，也可以输出SAX或DOM可以接收的格式。这个能力可以使Jdom很好的和已有的用SAX或DOM建立的系统之间整合。
Jdom的原则
第一条并且是最重要的一条就是Jdom的api函数被设计成对java程序员来说是简单易懂的。其他的XML解析函数被设计成语言通用的（支持相同的api函数在java，c++，甚至是javascript中）。Jdom利用了java的优秀的特征，如：方法重载、回收机制，和后台处理等。
为了能够简单易用，这些函数不得不以程序员喜欢的形式来描绘XML文档。例如：程序员想的到的一个元素的文本内容是什么样子的呢？
＜element＞This is my text content＜/element＞
在一些api中，元素的文本内容仅被当作是一个元素的孩子节点。从技术角度来说，这个设计需要下面的代码才能访问到元素的内容：
String content = element.getFirstChild().getValue();
Jdom用一种更简单易用的方法来取得元素的内容：
String text = element.getText();
Jdom尽可能的减少程序员的工作量。依据拇指规则，Jdom应该用20%或是更少的努力来完成80%或是更多的java/xml方面的问题。这并不是说Jdom只是支持80%的XML规范（实际上我们希望Jdom100%的支持XML规范）。这个拇指规则是说有些东西可以加进去，但是没有必要。这些api函数应该保持简洁。
Jdom的第二条原则是说Jdom应该是快速的和轻量级的。调入和执行文档应该快速，内存的消耗应该尽量小。Jdom的设计明显是遵循这个原则。例如，就算在开始的时候，不太协调的操作已经比DOM快，但是比SAX显的粗糙。尽管这样，Jdom还是有许多SAX没有的优点。
你需要Jdom吗？
那么，你需要Jdom吗？这真是一个很好的问题。已经有了存在的标准，为什么还要去发明一个新的呢？答案是Jdom解决了现有的标准解决不了的问题。
DOM完全在内存中描述一个元素树。它是一个大的api，被设计操作几乎所有可能的XML任务。它也必须有相同的api去支持不同的语言。因为这些限制，对那些习惯使用java的特征，如方法重载、简单的set,get方法的java程序员来说，就很不习惯。DOM还需要大量的内存和较高的主频，这使它很难和许多轻量级的web应用一起工作。
SAX没有在内存中建立一个元素树，它用事情发展的方式来描述。例如：它报告每个读到的开始标记和结束标记。这种处理方式使它成为一个轻量级的快速读取的api。然而，这种事件处理方式对服务器端的java程序员来说不够直观。SAX也不支持修改XML文档和随机读取。
Jdom试图组合DOM和SAX的优点。它被设计成一个可以在小内存上快速执行轻量级api 。Jdom也支持随机读取整个文档，但是令人惊奇的是它并不需要把整个文档读到内存中。这个api支持未来的当需要时才读入信息的次轻量级操作。还有，Jdom通过标准的构造器和set方法支持XML文档的修改。
获取XML文档
Jdom用org.Jdom.Document类的一个实例来描述一个XML文档。这个文档类是一个轻重量级的，它可以包括文档类型、多处理指令的对象、一个根元素和注释对象。你可以不需要构造器而从草稿构造一个文档。
Document doc = new Document(new Element("rootElement"));
本文后面我们会讨论从草稿构造一个XML文档是多么的容易。但是现在，我们从一个已存在的文件、一个流、或是一个URL路径中构造我们的文档。
SAXBuilder builder = new SAXBuilder();
Document doc = builder.build(url);
你可以用org.Jdom.input包中提供的构造类从任何数据源中构造文档。最近，有两种构造方式：SAXBuilder 和 DOMBuilder。SAXBuilder用sax解析器从文件中构造文档。SAXBuilder侦听sax事件并从内存中建立一个相应的文档。这种方式非常快（基本上和sax一样快），这也是我们推荐的方式。DOMBuilder是另一种可选的方式，它从一个存在的org.w3c.dom.Document对象中建立Jdom文档。它允许Jdom轻松的和构建DOM树的工具实现接口。
Jdom的速度有值得期待的提高的潜力通过一个延期的构造器的完成。这个构造器检查XML数据源，但当请求的时候才对它解析。例如：文档的属性当不访问时是不需要解析的。
构造器仍在发展，可以通sql查询、ldap查询和其他的数据格式来够造Jdom文档。所以，一旦进到内存中，文档就和建造它的工具没有关系了。
SAXBuilder 和 DOMBuilder构造器允许用户指明他们是否应该轮换，以便确定哪个解析器时间执行解析的任务。
public SAXBuilder(String parserClass, boolean validation);
public DOMBuilder(String adapterClass, boolean validation);
默认的是用apache的开源 Xerces解析器并且是关闭轮换的。你应该注到DOMBuilder不象一个解析类，倒更象一个适配类。这是因为不是所有的DOM解析器都是相同的api。为了仍让用户选择喜欢的解析器，Jdom使用一个对所有的dom解析器适用的公共的api的适配类。这个适配类支持所有流行的dom解析器，包括Apache 的 Xerces, Crimson，IBM 的 XML4J, Sun 的 Project X, 和Oracle 的 parsers V1 and V2.每一个解析器通过正确的调用别的解析器的方法执行标准的接口。这有点象jaxp，除了它支持jaxp所不支持的新的解析器。
你需要Jdom吗？
那么，你需要Jdom吗？这真是一个很好的问题。已经有了存在的标准，为什么还要去发明一个新的呢？答案是Jdom解决了现有的标准解决不了的问题。
DOM完全在内存中描述一个元素树。它是一个大的api，被设计操作几乎所有可能的XML任务。它也必须有相同的api去支持不同的语言。因为这些限制，对那些习惯使用java的特征，如方法重载、简单的set,get方法的java程序员来说，就很不习惯。DOM还需要大量的内存和较高的主频，这使它很难和许多轻量级的web应用一起工作。
SAX没有在内存中建立一个元素树，它用事情发展的方式来描述。例如：它报告每个读到的开始标记和结束标记。这种处理方式使它成为一个轻量级的快速读取的api。然而，这种事件处理方式对服务器端的java程序员来说不够直观。SAX也不支持修改XML文档和随机读取。
Jdom试图组合DOM和SAX的优点。它被设计成一个可以在小内存上快速执行轻量级api 。Jdom也支持随机读取整个文档，但是令人惊奇的是它并不需要把整个文档读到内存中。这个api支持未来的当需要时才读入信息的次轻量级操作。还有，Jdom通过标准的构造器和set方法支持XML文档的修改。
获取XML文档
Jdom用org.Jdom.Document类的一个实例来描述一个XML文档。这个文档类是一个轻重量级的，它可以包括文档类型、多处理指令的对象、一个根元素和注释对象。你可以不需要构造器而从草稿构造一个文档。
Document doc = new Document(new Element("rootElement"));
本文后面我们会讨论从草稿构造一个XML文档是多么的容易。但是现在，我们从一个已存在的文件、一个流、或是一个URL路径中构造我们的文档。
SAXBuilder builder = new SAXBuilder();
Document doc = builder.build(url);
你可以用org.Jdom.input包中提供的构造类从任何数据源中构造文档。最近，有两种构造方式：SAXBuilder 和 DOMBuilder。SAXBuilder用sax解析器从文件中构造文档。SAXBuilder侦听sax事件并从内存中建立一个相应的文档。这种方式非常快（基本上和sax一样快），这也是我们推荐的方式。DOMBuilder是另一种可选的方式，它从一个存在的org.w3c.dom.Document对象中建立Jdom文档。它允许Jdom轻松的和构建DOM树的工具实现接口。
Jdom的速度有值得期待的提高的潜力通过一个延期的构造器的完成。这个构造器检查XML数据源，但当请求的时候才对它解析。例如：文档的属性当不访问时是不需要解析的。
构造器仍在发展，可以通sql查询、ldap查询和其他的数据格式来够造Jdom文档。所以，一旦进到内存中，文档就和建造它的工具没有关系了。
SAXBuilder 和 DOMBuilder构造器允许用户指明他们是否应该轮换，以便确定哪个解析器时间执行解析的任务。
public SAXBuilder(String parserClass, boolean validation);
public DOMBuilder(String adapterClass, boolean validation);
默认的是用apache的开源 Xerces解析器并且是关闭轮换的。你应该注到DOMBuilder不象一个解析类，倒更象一个适配类。这是因为不是所有的DOM解析器都是相同的api。为了仍让用户选择喜欢的解析器，Jdom使用一个对所有的dom解析器适用的公共的api的适配类。这个适配类支持所有流行的dom解析器，包括Apache 的 Xerces, Crimson，IBM 的 XML4J, Sun 的 Project X, 和Oracle 的 parsers V1 and V2.每一个解析器通过正确的调用别的解析器的方法执行标准的接口。这有点象jaxp，除了它支持jaxp所不支持的新的解析器。
你需要Jdom吗？
那么，你需要Jdom吗？这真是一个很好的问题。已经有了存在的标准，为什么还要去发明一个新的呢？答案是Jdom解决了现有的标准解决不了的问题。
DOM完全在内存中描述一个元素树。它是一个大的api，被设计操作几乎所有可能的XML任务。它也必须有相同的api去支持不同的语言。因为这些限制，对那些习惯使用java的特征，如方法重载、简单的set,get方法的java程序员来说，就很不习惯。DOM还需要大量的内存和较高的主频，这使它很难和许多轻量级的web应用一起工作。
SAX没有在内存中建立一个元素树，它用事情发展的方式来描述。例如：它报告每个读到的开始标记和结束标记。这种处理方式使它成为一个轻量级的快速读取的api。然而，这种事件处理方式对服务器端的java程序员来说不够直观。SAX也不支持修改XML文档和随机读取。
Jdom试图组合DOM和SAX的优点。它被设计成一个可以在小内存上快速执行轻量级api 。Jdom也支持随机读取整个文档，但是令人惊奇的是它并不需要把整个文档读到内存中。这个api支持未来的当需要时才读入信息的次轻量级操作。还有，Jdom通过标准的构造器和set方法支持XML文档的修改。
获取XML文档
Jdom用org.Jdom.Document类的一个实例来描述一个XML文档。这个文档类是一个轻重量级的，它可以包括文档类型、多处理指令的对象、一个根元素和注释对象。你可以不需要构造器而从草稿构造一个文档。
Document doc = new Document(new Element("rootElement"));
本文后面我们会讨论从草稿构造一个XML文档是多么的容易。但是现在，我们从一个已存在的文件、一个流、或是一个URL路径中构造我们的文档。
SAXBuilder builder = new SAXBuilder();
Document doc = builder.build(url);
你可以用org.Jdom.input包中提供的构造类从任何数据源中构造文档。最近，有两种构造方式：SAXBuilder 和 DOMBuilder。SAXBuilder用sax解析器从文件中构造文档。SAXBuilder侦听sax事件并从内存中建立一个相应的文档。这种方式非常快（基本上和sax一样快），这也是我们推荐的方式。DOMBuilder是另一种可选的方式，它从一个存在的org.w3c.dom.Document对象中建立Jdom文档。它允许Jdom轻松的和构建DOM树的工具实现接口。
Jdom的速度有值得期待的提高的潜力通过一个延期的构造器的完成。这个构造器检查XML数据源，但当请求的时候才对它解析。例如：文档的属性当不访问时是不需要解析的。
构造器仍在发展，可以通sql查询、ldap查询和其他的数据格式来够造Jdom文档。所以，一旦进到内存中，文档就和建造它的工具没有关系了。
SAXBuilder 和 DOMBuilder构造器允许用户指明他们是否应该轮换，以便确定哪个解析器时间执行解析的任务。
public SAXBuilder(String parserClass, boolean validation);
public DOMBuilder(String adapterClass, boolean validation);
默认的是用apache的开源 Xerces解析器并且是关闭轮换的。你应该注到DOMBuilder不象一个解析类，倒更象一个适配类。这是因为不是所有的DOM解析器都是相同的api。为了仍让用户选择喜欢的解析器，Jdom使用一个对所有的dom解析器适用的公共的api的适配类。这个适配类支持所有流行的dom解析器，包括Apache 的 Xerces, Crimson，IBM 的 XML4J, Sun 的 Project X, 和Oracle 的 parsers V1 and V2.每一个解析器通过正确的调用别的解析器的方法执行标准的接口。这有点象jaxp，除了它支持jaxp所不支持的新的解析器。
