XOM API for Processing XML with Java

[Wolfgang Hoschek <whoschek AT lbl.gov>]

On Dec 10, 2004, at 12:28 PM, Elliotte Harold wrote:

> OK, now I'm getting somewhere. If I test with XOMChecker, which just 
> parses, instead of Reproducer, which copies, I don't see the cache 
> misses. I also see a third as many total hits. And I think that's the 
> clue I needed.
>
> The cache misses aren't coming from the Builder at all. They're coming 
> from the new elements created by Reproducer. And now that I look for 
> that I see the problem. It's this line:
>
>         Element copy = new Element(original.getQualifiedName(),
>           new String(original.getNamespaceURI()));
>
> What that call to a String constructor is doing there I don't know. 
> But it would break the interning. Taking it out, the cache gets hit 
> 100% of the time after each of the namespace URIs is seen once.
>
> So it looks like we can indeed use == for the comparison here. OK. 
> I'll make the changes in CVS. That's one mystery solved.

I see you figured it out. Just for completeness:


> Wolfgang Hoschek wrote:
>
> > I can't reproduce this with xerces-2.6.2, xom CVS and new 
> > Builder(false).build("/tmp/rddl.xml"), just using == and a cache size 
> > of 4, I get
>
> There's got to be some reason for this. I'm also using Xerces 2.6.2. I 
> miss the cache when I try with Crimson. I get the same results whether 
> I'm in Eclipse or at the command line. I get the same results when I 
> add Xerces to the bootclasspath instead of the classpath. Let me try 
> with 1.3 instead. Nope. Same result.
>
> Could this be a bug in Apple's string interning? Time to switch on the 
> Linux box and try that. Wolfgang, what OS/VM are you testing this on?

My results are from the command line with  
-Djava.endorsed.dirs=/path/to/xerces-2.6.2/ and on MacOSX (also the 
latest stable 1.4.2 JDK). With the crimson bundled with the JDK I get:

verifier cache = hits=1511, misses=17

which is slightly worse, but still more than good enough.

Wolfgang.