XOM and JDOM are completely separate products. Originally, I had thought I could build XOM by forking JDOM, but it quickly became apparent that it would be simpler to start over from scratch. Some early versions of XOM did use one class from JDOM (Verifier) in its internal, non-public parts. This class has been rewritten substantially; and in the current version there's no JDOM code left. The rest of the API is completely free of JDOM code.

Conceptually, XOM definitely did adopt a number of ideas from JDOM, including:

However, XOM also freely borrowed good ideas from DOM, XPath, and other systems, and invented not a few new ones of its own. Features in XOM that have no real equivalent in JDOM include:

There are also many features that JDOM and XOM share, but that are implemented very differently in the two APIs:

Finally, XOM hews closely to the motto that “Less is more.” It deliberately eschews the many convenience methods that make the JDOM API so cluttered such as getChildText/getChildTextTrim/getChildTextNormalize/getText/getTextTrim/getTextNormalize. If overloaded variants are included, there are nine separate methods for reading the text of an element. XOM has one, getValue. If you need to trim or normalize the value, you can use the methods of the String class.

No. XML 1.1 is an abomination. You don't need it and you shouldn't use it. In general, XOM focuses on giving developers what they need instead of what they think they want.

XOM 1.0 and 1.1 will not support XML 1.1. Possible future versions might, provided someone can demonstrate an actual need for it. The following are not legitimate needs:

You just might convince me you have a legitimate need for C0 control characters, but I doubt it. That still leaves a couple of possible uses for XML 1.1, but they're very obscure. (Do you speak Burmese?) Note that a hypothetical use-case is not going to do it. You're going to have to show me that you actually need to do this, and that you are going to use XOM.

Yes. All you really need is the xom.jar file. This contains all the core packages, but not the samples or unit tests. If you're using a Java virtual machine earlier than 1.4, you will probably also want to carry along the xml-apis.jar and xercesImpl.jar files from the lib directory. To use XSLT, you'll also need the xalan.jar archive. However, in Java 1.4 and later, you can get by without these. If you want to use normalization in the serializer, you'll need the normalizer.jar file. If you don't use normalization you can leave this out to. Even in Java 1.3 or 1.2 you can replace Xerces with a smaller parser. However, most parsers are buggier than Xerces, and no parsers prior to Xerces 2.6.1 can pass all XOM's unit tests.

If you want to trim XOM down even further, you can remove some of the non-core packages. All you really must have is in the nu.xom package. nu.xom.xslt, nu.xom.canonical, nu.xom.xinclude, and nu.xom.converters are only needed if you want their functionality. Nothing in the core nu.xom package depends on them.

There are a number of techniques you can use to speed up your XOM programs. Among them:

As a last resort, the Text class is optimized for size, not speed. If size is not a major concern, you can fork this class to make Text objects faster but larger. Making this a build-time option is on the TODO list, but has not yet been implemented.

Yes. If your documents are so large that you're running out of memory, you can use a custom NodeFactory to strip them down before processing. nu.xom.samples.NormalizingNodeFactory demonstrates how to strip boundary whitespace from record-like XML while building the document. If you only want some of the content in the input document you can go even further, simply not building any of the parts of the document that correspond to things you aren't interested in. You can drop out elements, attributes, comments, processing instructions, and so on.

If the document you've built is still too large to handle, then you can try processing in streaming mode inside the NodeFactory as the document is being read. This doesn't permit random access to the entire document at the same time, but it does allow you to process arbitrarily large documents in a reasonable amount of memory. There are several examples of this in the nu.xom.samples package: StreamingElementLister, StreamingXHTMLPurifier, StreamingTreePrinter, StreamingROT13, etc.

XOM requires Java 1.2 or later. It has been tested with Java 1.2.2_17, IBM's Java VM 1.3.1, Sun's JDK 1.4.2, IBM's JVM 1.4.1, and various betas of Java 1.5. A few of the unit tests fail in Java 1.2, but mostly these reflect encodings such as ISO-8859-6 that are not supported in that VM. All the core functionality is present.

It would probably not be hard to back port XOM to Java 1.1. The primary 1.2 dependence is the collections API, and this can be added to 1.1 as an extension. Alternately, collection classes such as ArrayList could be replaced with 1.1 classes such as Vector or implemented from scratch. However so far no one has expressed interest in running XOM in Java 1.1.

You should learn better than to believe everything you read on Slashdot. The LGPL is completely compatible with Java. Claims that it is not are based on severe misunderstandings of either Java, the LGPL, or both. The official word from the FSF's David Turner is,

If you would like a license to use XOM under other conditions, feel free to make me an offer. Non-LGPL, closed source licenses are available for a reasonable fee.

Like “new dot zom”.

No. I had no idea that the three letter extension for Omnimark files was .xom until someone brought it up in Q&A at my presentation at the New York XML SIG.

I'm somewhat familiar with the visitor pattern. I did explore it when I was first designing XOM. I'm still not convinced it really fits the XML problem space well. I don't like adding the extra method to Node just to support this. I may be wrong here. So far nobody's shown me convincingly how Visitor would make their life easier than using the more traditional navigation techniques. I'm inclined to agree with the DOM FAQ here:

Or at least I agree until someone shows me how much easier visitor would make important operations.

It's also a question of programmer familiarity. I think Visitor is one of those issues like interfaces vs. classes, push vs. pull, and pointers vs. stack variables, where the more advanced solution may be marginally better and more extensible for some uses, but really exceeds a lot of working programmers' comfort level. The level of abstraction and indirection can just get too high. Putting the client more in control is a lot more comfortable for most programmers since they can more easily see and visualize how the code flows. I am willing to trade some level of extensibility and generality in exchange for simplicity.

XOM does not have built-in support for schema validation. However, you can use a schema-validating SAX XMLReader which XOM will treat the same as a DTD-validating XMLReader. For example, suppose you want to use Xerces to perform schema validation. You would set up the Builder thusly:

  String url = "http://www.example.com/";
  try {      
    XMLReader xerces = XMLReaderFactory.createXMLReader("org.apache.xerces.parsers.SAXParser"); 
    xerces.setFeature("http://apache.org/xml/features/validation/schema", true);                         

    Builder parser = new Builder(xerces, true);
    parser.build(url);
    System.out.println(url + " is schema valid.");
  }
  catch (SAXException ex) {
    System.out.println("Could not load Xerces.");
    System.out.println(ex.getMessage());
  }
  catch (ParsingException ex) {
    System.out.println(args[0] + " is not schema valid.");
    System.out.println(ex.getMessage());
    System.out.println(" at line " + ex.getLineNumber() 
      + ", column " + ex.getColumnNumber());
  }
  catch (IOException ex) { 
    System.out.println("Due to an IOException, Xerces could not check " + url);
  }

There are two known failures that arise in some environments and not others. testBuildFromFileWithPlane1CharactersInTheName in BuilderTest fails on the Mac. This test exposes a bug in the Mac OS X Java VM. The test passes on other platforms.

Several of the tests in XSLTransformTest including testOASISXalanConformanceSuite, testOASISMicrosoftConformanceSuite, and testKeysPerfRepro3 fail in Java 1.4 due to bugs in the version of Xalan bundled with Sun's JDK. These tests pass in Java 1.5. They will also pass in Java 1.4 if you put the version of Xalan found in the lib directory in your jre/lib/endorsed directory so it will override the one bundled with the JDK. You can find out which version of Xalan you have by running "ant version" in the main XOM directory. You'll need 2.6.1 or later for all the test to pass.

xsl:output has no relevance to tree construction, only to the serialization of the result tree as text. Since XOM's XSLT constructs a result tree, but does not serialize it, xsl:output has no effect. You can set any necessary serialization options directly on the Serializer.