XOM API for Processing XML with Java

[Wolfgang Hoschek <whoschek AT lbl.gov>]

On Aug 12, 2004, at 4:20 AM, Elliotte Rusty Harold wrote:

> > Question: Would it perhaps be better to have static Builder.create 
> > methods instead of constructors?
>
> I don't want to make any such large change at this late date.

I understand the sentiment, hence the question.

> > That way one would gain a little flexibility in how/what kind of 
> > builder is returned. For example,
> > one could (in some later XOM release) conceivably return a builder 
> > from a thread local pool or similar (recognizing that constructing 
> > the underlying XMLReader of a Builder is an extremely expensive 
> > operation; takes 2 milliseconds or more).
>
> 2 ms is not a long time for an operation that happens approximately 
> once per thread. Builders are intended to be reusable in series. You 
> should not need to create a lot of them.

Sure, 2ms is not a long time for an operation that happens once per 
thread.

But in order to achieve that the only effective way I can see is to use 
a ThreadLocal similar to what I outlined in my previous mail if you
consider a reusable stateful user class with a method getNextXomDoc() 
or similar, not just a simple demo method looping over some XML files.
(An alternative, simply putting a large synchronized{...} around the 
use of the builder locks out other threads for a very very long time, 
and hence is pretty ineffective.) I'd be surprised if most people use 
that or even know about ThreadLocals. The bottom line is that I'd be 
surprised if many people use Builder in an effective way.

As an aside, note that in my example Threadlocal use I need to create 
the XMLReader manually if schema validation is desired, and all nice 
benefits of the Builder auto-parser detection internals get lost, 
because they are private to the Builder. So this is a a little nuisance 
and not very general.