Name: rmT116609 Date: 05/06/2004


A DESCRIPTION OF THE REQUEST :
A lot of applications are parsing text data, and among those missing classes there's a need for a StringBufferReader.

JUSTIFICATION :
Using a StringReader requires creating an instance of a new String, which unnecesarily allocates a new Object for the String, a char[] Object for the backing store, and a corresponding buffer for the copy. This just wastes resources in many parsers.

Almost all I/O routines should be able to work not only on a simple immutable String, but also on a StringBuffer (or even a char[] array with start/end indexes.)


EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
StringReader should simply be reimplemented with a StringBufferReader, i.e. a reader that reads from a StringBuffer, the most convenient source of data for text parsers that process lines one at a time, of various size, reusing the same StringBuffer to read each line of the file. Once a line is processed, StringBuffer.setLength(0) would be used to reset the input and refill it, without adding more allocations for the backing store. That StringBuffer could then be parsed by the application using a StringBufferReader with the same API as the existing StringReader, but without needing to instanciate a new immutable String object for the line to process.
ACTUAL -
For now the only way is to use StringReader(buffer.toString()), which has the inconvenient of transforming a mutable StringBuffer into a immutable (shared) status, meaning that the next call to buffer.setLength(0) will reallocate a new backing store for the StringBuffer, so the optimization of space allocation for the backing store is lost.

Another way is to use StringReader(new String(buff)) which does not change the mutable status of the StringBuffer (whose content is not shared for the new String), but it also requires allocating a immutable copy of the buffer content to create the String instance. So this just saves some of the space needed at each line, as only the effective line size stored in the StringBuffer is allocated.

This causes bad performance of text parsers made with StringReader, when it would be much simpler to have StringReader reimplemented with StringBufferReader from which it could inherit.

For performance of all repetitive I/O operations, having to use immutable String objects is a bottleneck to solve, as it gives penalties in terms or allocated temporary Objects and arrays, and gives more work to the garbage collector.

There are several other RFEs in progress related to StringReader. MAy be there's a need to review them for performance and flexibility by extending those classes which are only available in terms of immutable String objects.


CUSTOMER SUBMITTED WORKAROUND :
For now, when perfomance is needed, all we can do is to implement our own reader on StringBuffers with mutable content and reused backing stores.
(Incident Review ID: 236931)
======================================================================