What replaces StringBufferInputStream

T

Thomas Hawtin

Chris said:
(Incidentally, part of the problem is the non-symmetry in the existing names.
"Reader" and "InputStream" do not follow the same grammatical pattern.
While -- as it chances -- you can qualify "Reader" with "InputStream", the
reverse doesn't sit happily).

There isn't really a particularly good reason to expose the class.
Instead of introducing a new public class, a method would do:

public static InputStream asInputStream(Reader reader, Charset cs)

As Reader is a class, you could even add it as a member.

Tom Hawtin
 
P

Patricia Shanahan

Thomas said:
There isn't really a particularly good reason to expose the class.
Instead of introducing a new public class, a method would do:

public static InputStream asInputStream(Reader reader, Charset cs)

As Reader is a class, you could even add it as a member.

Although it certainly COULD be done that way, it would be inconsistent
with the general design of java.io.

It might have been better if it were done that way from the start, with
a visible class if, and only if, the new class adds some functionality,
such as a readLine() method.

For example, FileInputStream could have been replaced by a series of get
methods equivalent to its constructors:

public static InputStream fileAsInputStream(File f)

etc.

However, I don't think it is worth breaking the pattern now. To me, an
InputStreamReader sounds like a Reader that reads an InputStream, so I
like the name.

Patricia
 
M

Mike Schilling

Chris Uppal said:
Mike Schilling wrote:

[me:]
Those are worse than InputStreamReader and OutputStreamWriter because ...
? :)

Well, since you ask...

They are confusingly similar to pre-existing classes.

They violate rules of English phrase construction, and class name
construction
based on that.

(Incidentally, part of the problem is the non-symmetry in the existing
names.
"Reader" and "InputStream" do not follow the same grammatical pattern.
While -- as it chances -- you can qualify "Reader" with "InputStream", the
reverse doesn't sit happily).

A FileInputStream is an input stream that gets bytes from a file, and a
ReaderInputStream would be an input stream that gets bytes from a Reader.
 
D

Dale King

M.J. Dance said:
Well. There are cases where you can't do without bytes. Cryptography,
digests, signing etc. all operate on bytes. And people do want to
encrypt, digest and/or sign text (t.i. a string of characters) from time
to time.

And I didn't say that people could do without bytes. Of course, they
want to do those things, the question is directionality (read vs.
write). It makes a lot of sense to encrypt a string to write it to some
external entity. It's hard to come up with a compelling case where you
need to read from a String as encrypted bytes.
Even if not all the readers/writers are wrapped around a stream, there
could be a public getInputStream(...) or getOutputStream(...). It would
just throw an OperationNotSupportedException or something.

Don't follow you here.
 
P

Patricia Shanahan

Dale said:
...
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.

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.

ReaderInputStream and WriterOutputStream would have solved my problem
completely.

Patricia
 
D

Dale King

Patricia said:
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.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,483
Members
44,902
Latest member
Elena68X5

Latest Threads

Top