XOM API for Processing XML with Java

[Wolfgang Hoschek <whoschek AT lbl.gov>]

Sorry, I take that back. String.subString still does sharing in 1.5. I 
was looking at the wrong constructor - the public one that makes a 
copy. There's a private constructor that still does sharing, and that's 
the one used by String.subString(). End of emergency :-)

Wolfgang.

> > Wolfgang Hoschek wrote:
> >
> > > Another, unrelated thing to note is that JDK 1.5 nomore does 
> > > String.subString() sharing. It's good news since it can eliminate 
> > > hidden memory leaks, and it's bad news since it can produce tons of 
> > > memory overhead where code implicitly assumes that substrings are 
> > > shared. For example, Element.prefix and Element.localName come to my 
> > > mind. Even if a prefixed qname is constant, new copies are generated 
> > > by the internal design of Element, and, worse, semi-permanently 
> > > stored in Element. Same for Attribute.
> >
> > Oh crap. This is what I hate about optimization. You get it just 
> > right, and then everything changes. Does this mean I should be 
> > calling intern on the prefixes and local names? Or does substring at 
> > least do that in 1.5?
> >
> > I'll look at this, but I'm not going to make any 1.5 specific 
> > optimizations for at least the next few months. Right now the prime 
> > target is Java 1.4. Sometime down the road, I'll think about 
> > targeting 1.5 instead.
>
> Yep, taking care of the substring issue for 1.5 would require a lot 
> more invasive internal changes than anything we've been talking about 
> so far, so delaying that until a good scheme comes to light and proves 
> itself seems the best approach.
>
> Calling String.intern() is not a good idea, IMHO. intern() has lots of 
> problems, it's very slow (native method that jumps back and forth many 
> times between native and java code for each call. Interned strings may 
> never be garbage collected, if you're out of luck, etc. Might be 
> better to consider an application level string pool, per XOM document, 
> taking care of qnames, URIs, etc., perhaps a little along the lines of 
> the string pool internally used by bnux.
>
> Another approach might be to just store qnames directly, and compute 
> rather than store prefix and localName. Would probably lead to 
> internally rewriting quite a few XOM methods, e.g. in the 
> nu.xom.Serializer
>
> With some more though once could find other lines of attack as well, 
> i'm sure.
>
> Wolfgang.
>
> _______________________________________________
> XOM-interest mailing list
> XOM-interest AT lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/xom-interest