[jdom-interest] StringReader versus StringBufferInputStream

[Philipp Gröschler]

> I'm pretty sure that if you have your content as a
> String already, StringReader is the optimal choice.
> You do not need any char encoding/decoding; if you did
> create a stream, that first encode characters into
> bytes, then xml stream reader would decode characters
> from those bytes. Further, StringReader is as
> efficient as it gets, for reading stuff from Strings
> using Reader interface.

Thanks a lot for this statement. I was struggling with a similarly
proplem around two o'clock in the morning ;-)

So the steps

- reading a String with ResultSet.getString () from the database
- creating the StringReader
- parsing whatever comes with SAXBuilder.build (StringReader ...)

do ensure that the encoding of the String that comes from the database, and
so my original data, is not lost during the whole action? Assume that there
is no DOCTYPE at the start of the string.

> The overhead of SAXBuilder in itself is not high, the problem comes from
> the underlying SAX parser. Creating a new Xerces instance for example
> requires a fair amount of CPU.

So when does it occur that an new Xerces instance is needed? If a SAXBuilder
instance is not thread safe, and I need one in my servlet's service-method,
where do I create the builder object? If the only way is to use a
ThreadLocal variable, I'll try the code example. Or maybe I'll create my own
pool of builder objects directly in (my own) servlet engine.

Thanks,

Philipp