XOM API for Processing XML with Java

[Wolfgang Hoschek <whoschek AT lbl.gov>]

> 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.