Slowness of JDK 1.1.x String.intern() [was Re: SAX, Java, and Namespaces ]

Jeff Greif jmg at
Fri Feb 5 18:15:20 GMT 1999

JDK 1.1.7 intern is native, but is slow because it first converts the
characters in the string from unicode to UTF-8 in a freshly malloc'ed
buffer.  The buffer is later freed if the string is already interned.  It is
stored in the string table along with the String if not already present.  It
would be much better if a fixed-sized buffer for small strings and an
alloca()'ed or malloc'ed  buffer for larger ones were used, since the lookup
operation has the option of copying the string if it needs to be inserted.
I've sent Sun a revised version, but don't know whether or when it will be


-----Original Message-----
From: Tyler Baker <tyler at>
To: Tim Bray <tbray at>
Cc: David Megginson <david at>; xml-dev at
<xml-dev at>
Date: Thursday, February 04, 1999 5:48 PM
Subject: Re: SAX, Java, and Namespaces (was Re: Restricted Namespacesfor

... earlier stuff snipped ...
>As I said before things have improved.  intern() is now native so there is
really no excuse
>that I can think of why it should still be slow (it is not as slow as it
used to be but
>calling it has roughly half the cost of calling new() now).  Nevertheless,
the String class
>should of had a static intern() method a long time ago that accepts a
character array.  Boy
>would it have been convenient...

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at
Archived as: and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:majordomo at the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at

More information about the Xml-dev mailing list