Simplifying XML Programming with Jdom

As a developer, you may have heard of the 80-20 rule, which is called the Pareto rule in other areas: a process or method that adapts to 80% of all possible situations, and another 20% that needs to be dealt with in a specific situation. The corollary of software development is that for developers, with a given technology, 80% of the work that might be done can be done very easily.

Of course, software products and standards do not always evolve according to the 80-20 rule. In particular, the flaw in Java XML is an exception to this rule. The Java programming world has a lot of APIs--some developed by itself, some developed by several large companies and set up as standard--and they provide a mature solution for special XML tasks. As proof of the universality of XML, there is a new technology for each task, but how do we combine them and find the right tool to do 80% of the tasks that must be repeated-using the basic XML tree operations of the Java language's intuitive image? JDOM is just one of the XML APIs used to solve the above problems.

In many ways, the Java language has become a programming language for XML selection. Because of the pioneering work done by the Apache Software Foundation and IBM Alphaworks, there is now a complete tool chain for creating, manipulating, transferring documents, and parsing XML documents.

However, while many Java developers are using Xml,sun every day, they are lagging behind in integrating XML into the Java platform. The Java 2 platform has become very popular since XML became a key technology for business integration into WEB site content pipelining. It has been widely accepted that Sun has used the JSR process to make it the originator of an existing XML API. The most notable is the addition of JAXP (the Java API for XML parsing), which includes three packages:

Org.w3c.dom, a Java tool recommended by the Consortium for the XML standard programming Document Object model

Org.xml.sax, an event-driven simple API for parsing xml

Javax.xml.parsers, a Factory tool that allows application developers to obtain and configure Special parser tools

While it's good for Java developers to have these packages, it simply represents a formal license to the existing API standards and does not make a huge leap forward in providing best-in-class java-xml interoperability. What the core Java platform lacks is the intuitive interface for manipulating XML documents as Java objects.

Into the JDOM. JDOM is the creation of two renowned Java developers and authors, Brett McLaughlin and Jason Hunter, and in early 2000, with the permission of the Apache protocol, JDOM was formally developed as an open source project, JDOM as a The Open source project has officially begun. It has grown into a system that includes submissions from a wide range of Java developers, centralized feedback and bug fixes, and is committed to building a complete Java platform based solution that accesses, operates, and outputs XML data through Java code.

This is the JDOM suitable API, dummy element

JDOM can replace the Org.w3c.dom package to work with XML documents in a planned manner. It's not a simple alternative, and in fact JDOM and DOM can coexist happily. In addition, although the encapsulation of the class provided by it provides a significant amount of work from the configuration and run parser execution, it is not responsible for parsing the XML based on text input. JDOM is built on the capabilities of existing APIs, as the Project Web page describes as "a better mousetrap."

To understand why a standby API is needed, consider the limitations of the DOM design of the consortium:

Language independence. DOM is not designed in the Java language that people have in mind. While this approach preserves APIs that are very similar in different languages, it also makes it more cumbersome for programmers who are accustomed to the Java language. For example, a String class was built in the Java language, while the DOM specification defined its own Text class.

A strict hierarchy. The DOM API directly follows the XML specification. In XML, everything is a node, so you can find in the DOM a node-based interface and a series of methods to return node, which can be extended in almost every thing. In terms of polymorphism, it is excellent, but given the explanation, its application in the Java language is difficult and inconvenient, with the explicit drop-down of the Node to the leaf type causing the code to be lengthy and incomprehensible.

Interface driver. The common DOM API is composed only of interfaces (the Exception class is an exception, but just enough). The consortium is not interested in providing implementations, it is only interested in defining interfaces (more meaningful). But it also means that the use of APIs as Java programmers increases the degree of fragmentation in creating XML objects because the standard of the consortium uses a large number of industrialized classes and similar flexible but not straightforward patterns. In some applications, XML documents are created only by the parser and are never built by application-level code, which is irrelevant. However, as XML is used more widely, not all problems continue to be driven by the parser. Developers of applications need a more convenient way to construct XML objects systematically.

For programmers, these constraints mean large (in memory footprint and interface size) and difficult to master APIs, learning and use are difficult. Instead, JDOM is developed as a lightweight API, most notably Java-centric. It eliminates these drawbacks on the basis of following DOM's primary rules:

JDOM is dedicated to the Java platform. Whenever possible, the APIs are supported using the built-in string of the Java language, so the text values apply to string as well. It also leverages the Java 2 platform's class set, such as List and iterator, to provide programmers with a rich and similar Java language environment.

There is no level of hierarchy. In JDOM, an XML element is an instance of an element, and an XML attribute is an instance of an attribute, which is an instance of the document itself. Because all of these represent different concepts in XML, they are always referenced as their own types, rather than as a vague "knot".

Class-driven. Because JDOM objects are direct instances of classes like Document, Element, and Attribute, creating a new JDOM object is as easy as using the new operator in the Java language. It also means that there is no need for a factory interface configuration--the use of JDOM is straightforward.

Look, there's no Node: Create and manipulate JDOM documents

JDOM uses the standard Java encoding pattern. Whenever possible, it uses the Java new operator without complex Factory mode, making object manipulation even for novice users. For example, let's look at how to use JDOM to build a simple XML document. The structure we are going to build is shown in Listing 1.