Skip to Content.
Sympa Menu

xom-interest - Re: [XOM-interest] Text.java path for optional builds

xom-interest AT lists.ibiblio.org

Subject: XOM API for Processing XML with Java

List archive

Chronological Thread  
  • From: Wolfgang Hoschek <whoschek AT lbl.gov>
  • To: Elliotte Harold <elharo AT metalab.unc.edu>
  • Cc: xom-interest AT lists.ibiblio.org
  • Subject: Re: [XOM-interest] Text.java path for optional builds
  • Date: Sun, 19 Dec 2004 22:35:35 -0800

I am thinking about this. It's a reasonable thing to do, and I would like to provide some sort of switch that selects between a speed-optimized and a space optimized XOM. Ideally I'd like that to be settable at runtime or even on a per-document or per-builder basis. However, do far I haven't come up with any such approach I like so a compile time switch might be the best option.

If a better way of doing it should one day come up, the compile time option can always be removed again.


I'm not sure if this build file approach is the right way to do this compile time switch or not, or if it needs to be tweaked in some way. Further thoughts and suggestions about that are appreciated.

One thing that does concern me is testing. Testing gets exponentially complex with each extra compile time option we add. There are actually a lot of hidden options already: what parser is in the classpath; what version of the JDK is being used; what platform the tests are running on, etc. Some of the tests deliberately turn themselves off in certain environments where they don't really apply. Actually testing every line of code in XOM requires running on at least two platforms and with at least two different versions of Java, possibly more. JUnit doesn't really handle this very well. or at all. :-( If we add this I'd like to be able to automatically run all tests with both versions of the Text class. I'm not sure how easy that would be to do. It would roughly double the amount of time required to run the test suite though.

I can see the general issue, but given that both versions of Text.java are really trivial, I'd be suprised if there'd ever be a correctness issue with it. There's not much that can go wrong there anyway.


There is another thing that concerns me. Hidden in my pantry is a serializer that's significantly faster than XOM's default serializer. It gets the extra speed by offering no options. It just serializes the document in straight Unicode, without any indenting or other issues. I've been debating how or whether to introduce it. The proposed patch might slow that serializer down since it would require converting the strings to UTF-8, rather than just blasting the UTF-8 onto the OutputStream.

Why would there be a performance difference with the optional Text version? The old Text converts to UTF on setValue(), the new one later on serialization. Both convert once and only once. BTW, how much faster is your pantry serializer, and under which circumstances?

BTW, is there any particular reason that such a UTF8Serializer would need to be public? Perhaps the standard serializer can just look at the option values given to the serializer, and if they are such that the your scheme applies (e.g. equal to the defaults), it could just delegate to an internal UTF8 specific class. The advantage is that the user sees the same old API and semantics, and optimizations are purely internal.


Any way, as I said this is on my radar screen. Possibly it will get deferred into 1.0.1, or possibly it will make it into 1.0 if I can be convinced of the "right" way to do this before the XInclude working group finishes XInclude 1.0 recommendation, which is the major remaining blocker for 1.0. By the way, John, any progress on that front? Either way, since this proposal doesn't affect the public API, I can roll it in later even if it doesn't make it in now.

You could roll in the build option now, and remove it later if a better approach comes up. It would be no big compatibility deal as far as I can see.

Wolfgang.





Archive powered by MHonArc 2.6.24.

Top of Page