XOM API for Processing XML with Java

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

At 2:23 PM -0800 3/13/04, Wolfgang Hoschek wrote:
> Thanks, works fine for me.
>
> BTW, on a different issue: what's the purpose for sealing the xom 
> jar? Doesn't strike me as important.
> Plus, it makes patching xom less straightforward. For example up 
> until now i could have the patched nu.xom.converters.DOMConverter in 
> my own project jar (and tree), and by virtue of this class or jar 
> file being before xom.jar in the classpath the patch gets used 
> instead of the original. This is handy in many ways. It also does 
> not require distributing a patched (non-standard) xom.jar. With 
> sealing this does not work anymore.

> Why seal something that is open source anyway?

I'd rather people subclass than fork, and if they do fork I want it 
to be really obvious that that's what they're doing; and ideally they 
should give it a completely different name.

But the biggest reason is that if I don't seal, then it's way too 
easy to violate XOM's constraints by accessing package protected 
parts of the API, in which case a lot of things are likely to break. 
There's a lot of code in XOM that is optimized by assuming certain 
things "can't happen." For instance, a program that deletes the root 
element from a document could easily get stuck in an infinite loop.
--

  Elliotte Rusty Harold
  elharo AT metalab.unc.edu
  Effective XML (Addison-Wesley, 2003)
  http://www.cafeconleche.org/books/effectivexml
  http://www.amazon.com/exec/obidos/ISBN%3D0321150406/ref%3Dnosim/cafeaulaitA