String interning (WAS: SAX2/Java: Towards a final form)
Miles Sabin
msabin at cromwellmedia.co.uk
Thu Jan 13 18:05:11 GMT 2000
David Brownell wrote,
> Miles Sabin wrote,
> > Except that String.intern() isn't the _only_ way of
> > making foo.equals(bar) iff foo == bar (in particular
> > contexts, as opposed to across the whole JVM).
>
> It's the only way to ensure it's so if foo is a string
> literal, as is rather common usage.
I don't follow. You're surely not suggesting that
foo == "literal".intern()
is faster than,
foo.equals("literal")
are you?
I assume not, but then I don't really see your point. It'd be
easy enough to pre-populate an app-intern map with all the
literals you were interested in. Granted, getting any benefits
from this in a ContentHandler (as opposed to in a parser
implementation) would mean we'd need something akin to Lars
StringInterner interface to do the pre-populating.
Anyhow, maybe the waters are getting a bit muddied. I'm
assuming that all parsers will do interning of one sort or
another internally. The issue for me is how much of that gets
exposed via the SAX API. I don't want java-interning exposed,
because that means my parser has no option but to use
String.intern().
OTOH, _if_ the consensus is that some sort of interning must be
exposed for the convenience of ContentHandler implementors then
I'll go along with it, just so long as it's specified in such a
way that it can be implemented in a completely thread-local
way.
But I'd much prefer it if the SAX API didn't expose any
interning behaviour at all. I think we agree on that?
Cheers,
Miles
--
Miles Sabin Cromwell Media
Internet Systems Architect 5/6 Glenthorne Mews
+44 (0)20 8817 4030 London, W6 0LJ, England
msabin at cromwellmedia.com http://www.cromwellmedia.com/
xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ or CD-ROM/ISBN 981-02-3594-1
Please note: New list subscriptions now closed in preparation for transfer to OASIS.
More information about the Xml-dev
mailing list