[jdom-interest] Reference comparisons in SAXHandler.startElement

Rosen, Alex arosen at silverstream.com
Tue Mar 13 15:44:01 PST 2001


I guess what I'm proposing is that the JDOM code shouldn't try to do anything
clever in this area (by using intern() or ==).

I remember some time in the late JDK 1.1 or early JDK 1.2 timeframe, Sun
engineers were basically saying that intern() wasn't worthwhile - it often
slowed things down more than it sped things up. I don't know about memory
usage, though. Do we think that it's currently useful? Presumably there's a
reason that Xerces decided to do their own interning. I'd be inclined to just
let the parser do whatever it wants, and use .equals() to be on the safe side.

If we've seen that the standard String.intern() provides substantial
performance benefits, then disregard this argument, and I agree with your plan.

Alex Rosen
SilverStream Software

> -----Original Message-----
> From: Jason Hunter [mailto:jhunter at collab.net]
> Sent: Tuesday, March 13, 2001 6:27 PM
> To: GB/DEV - Philip Nelson
> Cc: 'Rosen, Alex'; jdom-interest at jdom.org
> Subject: Re: [jdom-interest] Reference comparisons in
> SAXHandler.startElement
>
>
> > Good point. On the other hand, when the strings don't match,
> > String.equals() is
> > usually going to discover this by examining just the first
> > character or two (in
> > the most common cases). Not as fast as ==, but it won't have
> > to check every
> > single character. It just doesn't seem like this optimization
> > is worth the bugs
> > it'll introduce.
>
> I never proposed to keep things as they are.  Check my previous post.
> My proposal is to intern in the constructor first thing and
> that doesn't
> allow for any "bugs" to slip through.  It's the same effect as turning
> on interning in the parser, but intead we explicitly turn it
> off in the
> parser and do it in JDOM so we gain the interning benefits for manual
> doc construction also.
>
> -jh-



More information about the jdom-interest mailing list