Skip to Content.
Sympa Menu

xom-interest - Re: [XOM-interest] Re: Last call

xom-interest AT lists.ibiblio.org

Subject: XOM API for Processing XML with Java

List archive

Chronological Thread  
  • From: Elliotte Rusty Harold <elharo AT metalab.unc.edu>
  • To: Wolfgang Hoschek <whoschek AT lbl.gov>
  • Cc: xom-interest AT lists.ibiblio.org
  • Subject: Re: [XOM-interest] Re: Last call
  • Date: Sat, 13 Mar 2004 18:10:53 -0500

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




Archive powered by MHonArc 2.6.24.

Top of Page