Re: What replaces StringBufferInputStream
Patricia Shanahan wrote:
Dale King wrote:
...
In this case the reason Patricia needs it is a poorly designed class.
Since that class expects to read textual data it should support
Readers. It could in addition support InputStream (although I would
mark that support as deprecated because users should not be using it).
I'm not so sure that classes such as Process should supply Reader/Writer
interfaces themselves. Process is providing access to byte stream data.
If it does it through Reader and Writer it would have to be told the
encoding (even if it also had a option for going with a default encoding).
Some applications might want direct, unconverted, byte stream access to
exactly what the job said. That might be important, for example, for debug.
I wasn't suggesting that Process should. If I understood your
explanation you are trying to test a class that process the output
streams of a Process. So I am imagining a class that has a constructor
that takes two InputStream objects, one for the output stream and one
for the error stream from the Process.
Since this class is really processing text information it should really
take two Reader objects. This makes the class independent of where the
actual data comes from (in your case from a String). If you wanted to
hook it up to the output of a Process you simply wrap the streams from
the Process in an InputStreamReader with the appropriate encoding.
This makes the class more general-purpose. Imagine for example if
instead of the data coming from another process on this machine you
instead sent off a SOAP message to another server and got a text
response back.
Given the general layering of I/O interfaces, I think it may be better
to just provide the Stream interfaces, and expect the caller to build
any Reader or Writer, passing the encoding information to the constructor.
If I understand what you meant, I think that is what I am suggesting.
ReaderInputStream and WriterOutputStream would have solved my problem
completely.
But unfortunately would invite much abuse by those who do not understand
the differences between text and raw bytes. I could see many newbies
using a ReaderInputStream when in reality they should be converting to
Reader.
--
Dale King