5 avg. rating (100% score) - 5880 votes
JDOM is, quite simply, a Java representation of an XML document. JDOM provides a way to represent that document for easy and efficient reading, manipulation, and writing. It has a straightforward API, is a lightweight and fast, and is optimized for the Java programmer. It's an alternative to DOM and SAX, although it integrates well with both DOM and SAX.
JDOM is not a wrapper for the W3C's DOM, or another version of DOM. JDOM is a Java-based "document object model" for XML files. JDOM serves the same purpose as DOM, but is easier to use.
JDOM is not an XML parser, like Xerces or Crimson. It is a document object model that uses XML parsers to build documents. JDOM's SAX Builder class for example uses the SAX events generated by an XML parser to build a JDOM tree. The default XML parser used by JDOM is the JAXP-selected parser, but JDOM can use nearly any parser.
JDOM is available under an Apache-style open source license, with the acknowledgment clause removed. This license is among the least restrictive license available, enabling developers to use JDOM in creating new products without requiring them to release their own products as open source. This is the license model used by the Apache Project, which created the Apache server. The license is available at the top of every source file and in LICENSE.txt in the root of the distribution.
All JDOM versions are available in the 'jdom' vs 'jdom 2' artifact in the org.jdom group on Maven. The maven artifacts are a mess with early JDOM 2.x versions appearing in the 'jdom' artifacts, and later 2.x versions in the 'jdom 2' artifact. Maven does not allow the fixing of mistakes, so maven users wil just have to live with it as it is.
If your project is one that requires both JDOM 1.x and 2.x, then you can also use the 'jdom-legacy' artifact to pull in version 1.1.3 (or later 1.x version).
JDOM has been and will continue to be developed with this philosophy:
This issue has been discussed several times on the JDOM mailing list, with several people on both sides. In general, many people feel that a class-based API is better when sub classing is not needed, while an interface-based API is better when sub classing is needed. However, either system can be used in either case.
Jason Hunter summarizes the arguments against an interface-based API for JDOM:
Think about java.io.File as an analogy.
There's a reason we say:
File parent = new File (file path);
File child = new File (parent, "aaa.txt");
FileSystem fs = FileSystem.getDefaultFileSystem ();
File parent = fs.getFile (file path);
File child = fs.getFile (parent, "aaa.txt");
The former is simply easier and nicer to deal with.
Another point to keep in mind is that anything that can be done with interfaces can be done with sub classing - the only penalty is possibly unused variables in the base class.
For reference, the latest mailing list discussion on this topic started Nov. 30, 2000 with "Interfaces", and continued with "Interface-based JDOM" and "Announce: JDOMPlus". It would help to review this discussion before bringing this topic up on the mailing list.
JDOM documents can be built from XML files, DOM trees, SAX events, or any other source. JDOM documents can be converted to XML files, DOM trees, SAX events, or any other destination. This ability proves useful, for example, when integrating with a program that expects SAX events. JDOM can parse an XML file, let the programmer easily and efficiently manipulate the document, then fire SAX events to the second program directly - no conversion to a serialized format is necessary.
JDOM was designed before Generics, but JDOM 2.x has taken the proven design of JDOM 1.x and extended it to use Generics where possible. Specifically, all Collections-based operations require appropriately typed inputs, and return appropriately typed results. Further, JDOM 2.x takes advantage of other Java 5 features like varargs, and co-variant return types.
Generics: Element.getAttributes () returns List<Attribute>, Element.getChildren () returns List<Element>, etc.
Co-variant Return Types: Element. Clone () returns Element, Text. Detach () returns Text, etc.
I tried to use JDOM and get an error like this:
You need to ensure that the xerces.jar file supplied with the JDOM download is in your classpath before any other XML classes, such as those that come with JAXP or Crimson. These other XML libraries, as well as older versions of Apache Xerces, support DOM Level 1 and SAX 1.0, not the required DOM Level 2 and SAX 2.0. The result is an exception being thrown. Check your classpath, and try again. If the classpath looks OK, the problematic JAR might also be hiding in the system's standard extension directory.
The standard extension directory is a directory containing JAR files that is searched automatically by the Java runtime and compiler. If you've installed the JDK (not the just the JRE) you may well have two separate ext directories, one of which is used for compiling (typically somewhere like C:jdk1.3jrelibext) and the other of which is used for running code (typically somewhere like C:Program FilesJava Softjre1.3libext). The wrong JAR file in either directory can get in your way (though at different times). Furthermore, the right JAR file has to be in both directories.
When the WTE feature is added to the workspace, the project 'IBM XML Parser for Java' is added as well. This project contains old DOM Level 1 'org.w3c.*' interfaces. JDOM relies on DOM Level 2, and therefore conflicts with this project.
The solution is to do the following:
WebSphere has the same issue with DOM Level 1 interfaces as VAJ above. The solution is to do one the following:
The JDOM 2.x development process included benchmarks for tracking performance changes. There are performance numbers comparing different versions of JDOM 2.x as well as comparing the performance of JDOM on different JDK versions.
Dennis Sisonke in the past ran performance benchmarks. In general, most XML object models are in a similar neighborhood.
There are many ways to do XSL transforms with JDOM. The most straightforward way is to use the standard JAXP Transformer interface and the JDOMSource/JDOMResult classes found in the org.jdom2.transform package.
The core API is intentionally not thread safe. In other words, there are no synchronized blocks within org.jdom. This decision makes sense because we expect the primary JDOM use cases to be:
The use case where a "Single thread reads an XML stream into JDOM and exposes it to multiple threads to modify its contents" is fairly rare. In that case, JDOM can still be made thread safe but the programmer simply has to perform their own synchronization, perhaps as synchronizing on the Document instance.
On the other hand, there are certain functions that require 'operational' parts of JDOM to be thread safe:
In JDOM two Content objects are only equal if they're the exact same object. This lets a call like list. Remove (elem) remove only the exact Element passed in, not any element that's equivalent. That's a very important distinction. Doing a full equals() on an Element would require recursing down the tree, and in general we believe it unlikely you'll want to know if this element and all its children are equivalent to another one. If you really do want to know you can write some comparison code yourself that checks only as much as you want to check (maybe the name/namespaces only) instead of doing a full recurse.
The equals () methods are final for JDOM Content classes so that a subclass can't break the == behavior that's required for calls like list. Remove (elem) to work as designed. Similarly, the hashCode () methods are also final (to preserve the equals/hashCode contract).
You use standard Java IO library calls. Wrap the String with a String Reader and pass the reader to SAX Builder:
Document doc = builder. Build (new String Reader (xml));
Use the methods on the List returned by get Children () or get Content (). JDOM does not need special methods because the methods already exist in List.
For example to remove an element from a list of children:
List children = parent.getChildren ();
Children. Remove (element); // given child
Children. Remove (0); // first child
Other methods on List provide options to remove all children, add a child at a given location, and so on.
If you have a particular Element or other Content that you want to remove from its parent, you can detach the Content with the Content. Detach () method.
There's no need for node "importing" like there is with DOM. Just remove the element from its current place, and then add the element to its new place. The element's content (including its element children) will naturally "tag" along for the ride. You have to remove the element before adding it to its new place because elements may have only one parent returned by get Parent ().
new Parent.add Content (elt.detach ());
There's no need for node "importing" like there is with DOM. Just clone the element being copied and add its clone in its new place. You have to clone the element before adding it to its new place because elements may have only one parent returned by get Parent ().
newParent.addContent (elt.clone ());
The XML 1.0 specification specifically reserves the colon character for use with XML Namespaces. No other use is compliant with XML 1.0. Therefore JDOM does not allow you to create element and attribute names that contain colons except when using namespaces. Furthermore, because of the way namespaces are implemented in JDOM, you cannot simply create an Element or Attribute with a fully qualified name like svg: title.
That is you cannot do this:
Element e = new Element ("svg: title");
Instead you must split the two parts into a Namespace and a local name. This is the proper JDOM way to create an element in a namespace:
Element e = new Element ("title", "svg", "http://www.w3.org/2000/svg");
The first argument is the local name. The second argument is the prefix. The third argument is the namespace URI.
If you're trying to create the xml: Lang and xml: space attributes use:
Element e = new Element ("lang", Namespace.XML_NAMESPACE);
Specifically, for this XML fragment:
You need to use code like this:
Namespace ns = Namespace.getNamespace ("http://foo.com");
Element y = x.getChild ("y", ns);
Element z = y.getChild ("z", ns);
According to section 2.11 of the XML Recommendation, 2nd edition:
In other words, this is exactly what's supposed to happen.
When you pass a string into a method like set Text () JDOM assumes it's just that, a string, not a fragment of XML. For example, when you call:
element.setText ("  ;")
JDOM assumes you want to set the content to the string containing the six characters & # 1 6 0. It does not parse it to attempt to understand it as XML first. Thus when you output the text using XMLOutputter it will naturally escape the special ampersand character and output & #160. The solution is to pass regular Unicode characters to the set Text () method or, if you have text data that you want to be interpreted as XML, pass it through an XML parser before it goes into JDOM. This is what the SAX Builder and DOM Builder classes do.
Some parsers (Xerces include) use this exception as part of their standard operating procedure, internally throwing and catching the exception. No code outside the library is meant see it. However, IDE debuggers are often configured to report any time this exception is thrown, and thus they expose the exception. It can be safely ignored.
The default character encoding used by XMLOutputter is UTF-8, a variable-length encoding that can represent all Unicode characters. This can be changed with a call to format.set Encoding () on the Format object passed to XMLOutputter. It would be nice if XMLOutputter could default to the original encoding for a file, but unfortunately parsers don't indicate the original encoding. You have to set it programmatically.
This issue most often affects people with documents in the common ISO-8859-1 (Latin-1) encoding who use characters like ñ but aren't familiar with having to think about encodings. The tip to remember is that with these documents you must set the output encoding to ISO-8859-1, otherwise characters in the range 128-255 will be output using a double byte encoding in UTF-8 instead of the normal single byte encoding of ISO-8859-1.
Currently you can't do this, in JDOM or any other Java document object model API. However, this is something we'd like JDOM to support, and we have a volunteer who's working on it.
No, it's our current belief that it's better to expose a check Valid () type of call than to attempt constant validation checking. One reason is performance. A second reason is that you have a chicken-and-egg problem where for example an element needs exactly two child elements to be valid, but after adding either child the document will be in a temporarily invalid state. To work around this would require something like transactional modifications, and that's a lot of overhead for little gain.
For spam protection, only members of the mailing list may post. To post from multiple accounts, subscribe each account and set the "Disable mail delivery" feature to "On" for all the extra accounts.
The book covers an early beta. Much has changed (for the better) since publication of the book. For the most accurate JDOM API trust the Javadoc, not the book. Brett was a little optimistic when writing the book. His 2nd Edition sets things straight.
If you believe you found a bug in JDOM:
Jdom Related Tutorials
|Python Tutorial||Adv Java Tutorial|
|J2EE Tutorial||Core Java Tutorial|
|JSP Tutorial||Six Sigma Tutorial|
Jdom Related Interview Questions
|Python Interview Questions||Adv Java Interview Questions|
|J2EE Interview Questions||Core Java Interview Questions|
|JSP Interview Questions||Six Sigma Interview Questions|
|Hibernate Interview Questions||Java Developer Interview Questions|
|Java 9 Interview Questions|
All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd
Wisdomjobs.com is one of the best job search sites in India.