XOM API for Processing XML with Java

[Elliotte Rusty Harold <elharo AT metalab.unc.edu>]

I'm pleased to announce the release of XOM 1.0d14.

The primary focus of this release is speed. I've done extensive
profiling of the CPU times used by XOM, and rearchitected
classes to run faster by both macro and micro optimizations. One
of the things I discovered was that parsing and serialization
are dramatically slower than in-memory manipulations, typically
by three orders of magnitude. Right now my belief is that any
program that does any parsing or serialization (and it's hard to
imagine what program wouldn't do at least one of those two) is
going to spend so much time doing that, that nothing else is
worth optimizing. Parsing and serialization are typically three
orders of magnitude slower than in-memory manipulations, even
when all I/O is performed between byte arrays. There's simply no
point to optimizing anything else.

That said, I have optimized parsing/document building
extensively in this release. It is much, much faster than in
previous releases. It should now be competitive with any other
tree-based API written in Java, though naturally it's still
slower than a straight forward SAX parse because it sits on top
of SAX. The biggest effects on speed now are I/O (don't forget
to buffer your streams) and the speed of the underlying parser.
I'm still recommending Xerces because it's the only I've found
that's almost correct, but you can speed XOM up by a factor of a
third by switching to Crimson, and possibly more by switching to
Piccolo. However, both of those have nasty bugs that prevent the
XOM unit tests from completing successfully. Xerces has a couple
of bugs too, but fortunately nothing I couldn't work around.

Contrary to popular belief, most of the optimizations improved
both speed and memory use. There were few trade-offs between
them. However, there was one notable exception. The Text class
is now storing its data internally in UTF-8. This cuts memory
usage for documents containing mostly ASCII text by about 10-20%.
However, it has a noticeable 10% speed penalty. I'm not sure if
I'm going to keep this strategy or not. Ideally, I'd like to
provide some sort of runtime switch to select this behavior
(or not) but I haven't yet figured out the right design to make
this happen. The constraints on the design are:

  * There must be a simple public constructor in the Text class
  * There must be a simple setValue() method in the Text class
  * Subclasses from outside the nu.xom package cannot bypass
  verification
  * Each Text object should not carry around unnecessary fields
   (a four byte reference per object adds up fast.)
  * Frequently called methods such as getValue() and setValue()
   should not use instanceof. (Profiling has shown this is a
   performance killer.)

 There are no public API level changes in this release. However,
 the unit tests have been expanded dramatically, which resulted
 in the discovery and elimination of a number of bugs.

  * There are the beginnings of a new nu.xom.benchmark
  package, though it's not even close to stable yet. None of
  the classes in here are public, but you can run the programs
  to get some rough timing measurements.

  * Verification is not performed on build. Instead XOM relies
  on the parser to perform well-formedness checks. This is a
  significant speed-up.

  *  Worked around some bugs in Xerces that caused the wrong
  exception to be thrown when validating.

  * Improved compatibility with Crimson, the default parser in
  Java 1.4. However, Crimson bugs still prevent the
  canonicalization unit tests from completing successfully.
  (Specifically, it normalizes numeric character references
  such as 
 in attributes to spaces.). There's no easy
  way to work around this.

  * Element.insertChild(String, int) now throws a
  NullPointerException if the first argument is null

  * Fixed a nasty bug in Document's copy constructor that
  caused the prolog and epilog of a document not to be copied.

  * Disallowed fragment identifiers in system literal URI
  references, per conformance with the XML spec

  * Fixed several bugs involving the handling of notation and
  unparsed entity declarations in the internal DTD subset

  * Added unit tests for the internal DTD subset.

  * Fixed build.xml to point at Xerces properly. Consequently
  "build testui" now works

  * The API documentation for the nu.xom.samples package is no
  longer bundled with the main JavaDoc, to indicate that this
  is not really a part of the public API. For the moment, if
  you want this you'll have to build it yourself, though it's
  not very useful. I have not spent a lot of effort on the
  comments in the samples package.

I never announced 1.0d13 beyond this list. However, if nobody spots 
any showstoppers, I'll probably announce this release more broadly on 
Monday.
--

  Elliotte Rusty Harold
  elharo AT metalab.unc.edu
  Processing XML with Java (Addison-Wesley, 2002)
  http://www.cafeconleche.org/books/xmljava
  http://www.amazon.com/exec/obidos/ISBN%3D0201771861/cafeaulaitA