What replaces StringBufferInputStream

[Patricia Shanahan]

I need to generate an InputStream from a String containing some test data.

StringBufferInputStream is deprecated, and the documentation points to
StringReader.

However, after looking through java.io several times, I have not found
how to construct an InputStream from a Reader.

What is the proper, undeprecated, replacement code for:

InputStream in = new StringBufferInputStream(someString);

Thanks,

Patricia

 

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

I need to generate an InputStream from a String containing some test data.

StringBufferInputStream is deprecated, and the documentation points to
StringReader.

However, after looking through java.io several times, I have not found
how to construct an InputStream from a Reader.

What is the proper, undeprecated, replacement code for:

> InputStream in = new StringBufferInputStream(someString);

InputStream in = new ByteArrayInputStream(someString.getBytes(encoding));

must be a candidate.

Arne

 

[Patricia Shanahan]

InputStream in = new ByteArrayInputStream(someString.getBytes(encoding));

must be a candidate.

Arne

Thanks.

That works, and gets rid of the warnings. But why does the
StringBufferInputStream documentation say "As of JDK 1.1, the preferred
way to create a stream from a string is via the StringReader class." if
StringReader cannot do StringBufferInputReader's job?

Patricia

 

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

That works, and gets rid of the warnings. But why does the
StringBufferInputStream documentation say "As of JDK 1.1, the preferred
way to create a stream from a string is via the StringReader class." if
StringReader cannot do StringBufferInputReader's job?

I dont know.

A guess could be that a typical usage of StringBufferInputReader
was to wrap it in an InputStreamReader.

But this is pure guessing.

Arne

 

[John W. Kennedy]

I need to generate an InputStream from a String containing some test data.

StringBufferInputStream is deprecated, and the documentation points to
StringReader.

However, after looking through java.io several times, I have not found
how to construct an InputStream from a Reader.

What is the proper, undeprecated, replacement code for:

InputStream in = new StringBufferInputStream(someString);

From Java's viewpoint, you're looking at it wrong. In the normal case,
since 1.1, Java doesn't want you to use an InputStream for anything, but
a Reader (unless you need a DataInputStream).

Reader in = new StringReader(someString);

 

[Patricia Shanahan]

From Java's viewpoint, you're looking at it wrong. In the normal case,
since 1.1, Java doesn't want you to use an InputStream for anything, but
a Reader (unless you need a DataInputStream).

Reader in = new StringReader(someString);

I'm writing a unit test for a class that reads from InputStream. The
string contains the test data I want it to operate on.

The class I'm testing is intended to deal with the stdout and stderr
streams from a java.lang.Process job, and java.lang.Process does not
seem to have heard of Reader.

Patricia

 

[Chris Uppal]

From Java's viewpoint, you're looking at it wrong. In the normal case,
since 1.1, Java doesn't want you to use an InputStream for anything, but
a Reader (unless you need a DataInputStream).

Maybe that came out wrong, but taken literally it is completely false.
InputStreams are central to the IO architecture.

-- chris

 

[Chris Uppal]

But why does the
StringBufferInputStream documentation say "As of JDK 1.1, the preferred
way to create a stream from a string is via the StringReader class." if
StringReader cannot do StringBufferInputReader's job?

My guess is that they intended to create in InputStream-flavoured wrapper for
Readers, but never got around to it. Probably they argued for a few days about
what to call it, but could neither stomach ReaderInputStream nor agree on
anything else, and just quietly dropped it.

"Nobody's going to need it anyway"

;-)

-- chris

 

[Robert Klemme]

That works, and gets rid of the warnings. But why does the
StringBufferInputStream documentation say "As of JDK 1.1, the preferred
way to create a stream from a string is via the StringReader class." if
StringReader cannot do StringBufferInputReader's job?

Um, as far as I can see there is no StringBufferInputReader. The
replacement for StringBufferInputStream is InputStreamReader - the major
difference is that the latter properly deals with encodings. In your
case the default constructor is probably most appropriate because the
process will likely emit its output using the default encoding of the
platform. If not, you need a way to make sure the process and your
InputStreamReader use the same encoding.

HTH

Kind regards

robert

 

[Chris Uppal]

I'm writing a unit test for a class that reads from InputStream. The
string contains the test data I want it to operate on.

Wouldn't it make more sense to hold the test data in a byte[] array ? That,
after all, is what your real data will look like -- binary, coming from an
external application using who-knows-what encoding.

-- chris

 

[M.J. Dance]

What is the proper, undeprecated, replacement code for:

InputStream in = new StringBufferInputStream(someString);

There is no proper replacement. The line of code above is mixing two
superficially similar but inherently different things: bytes and chars. Of
course the two are related but, in order to fully describe that relatinship, one
needs additional information: character encoding. Having that, one can
getBytes() from a String and, using those, create a ByteArrayInputStream.

There are some inconsistencies in Java API as far as such situations are
concerned. Sun decided to deprecate a whole StringBufferInputStream (instead of
deprecating only a constructor and adding a new one specifying encoding). Yet
they chose a different approach with String for example. One can construct a new
String from an array of bytes despite the fact that by doing that, one relies on
default/platform character encoding. Assuming that this encoding is the right
one, one can get desired results. But we all know that assumption is the mother
of all FUs, don't we?


So, whatever you do, don't... ;-)

 

[Patricia Shanahan]

I'm writing a unit test for a class that reads from InputStream. The
string contains the test data I want it to operate on.

Wouldn't it make more sense to hold the test data in a byte[] array ? That,
after all, is what your real data will look like -- binary, coming from an
external application using who-knows-what encoding.

My real data is text. I find it much faster to write text as Strings.

The solution, as Arne pointed out, is to first get a byte array from the
String. If internationalization were an issue, I would specify an
encoding on that conversion.

In the real application, the data will be coming from Matlab. The
application only needs to work on a few hundred systems, three of which
I control and the remaining systems are all part of a UCSD grid
computer, so I do know what encoding.

Patricia

 

[vahan]

As we know java String is char array. When we look through code source
for
StringBufferInputStream and StringReader read method we can see
difference
between:

StringBufferInputStream:
public synchronized int read() {
return (pos < count) ? (buffer.charAt(pos++) & 0xFF) : -1;

StringReader:
public int read() throws IOException {
synchronized (lock) {
ensureOpen();
if (next >= length)
return -1;
return str.charAt(next++);
}
}

As we see StringBufferInputStream's read method return only low byte
from char as int . That is why it is deprecated.
Best Vahan

 

[Patricia Shanahan]

As we know java String is char array. When we look through code source
for
StringBufferInputStream and StringReader read method we can see
difference
between:

StringBufferInputStream:
public synchronized int read() {
return (pos < count) ? (buffer.charAt(pos++) & 0xFF) : -1;

StringReader:
public int read() throws IOException {
synchronized (lock) {
ensureOpen();
if (next >= length)
return -1;
return str.charAt(next++);
}
}

As we see StringBufferInputStream's read method return only low byte
from char as int . That is why it is deprecated.
Best Vahan

I don't have a problem with StringBufferInputStream being deprecated,
and understand perfectly well why.

The question is what replaces it, when the recommendation in the
documentation, StringReader, does not seem to do the whole job, because
there does not seem to be any way to get from there to an InputStream.

Patricia

 

[Chris Uppal]

The solution, as Arne pointed out, is to first get a byte array from the
String. If internationalization were an issue, I would specify an
encoding on that conversion.

I'd still specify the encoding explicitly -- you may as well be clear on what
the test is actually testing.

BTW, I don't believe that character encodings should be thought of as just an
internationalisation issue. (And even they if were, you -- being a
foreigner -- shouldn't ignore those issues ;-)

Matlab's a powerful program; surely it can be told to produce its output in
UTF-8 or UTF-16...

-- chris

 

[Patricia Shanahan]

I'd still specify the encoding explicitly -- you may as well be clear on what
the test is actually testing.

BTW, I don't believe that character encodings should be thought of as just an
internationalisation issue. (And even they if were, you -- being a
foreigner -- shouldn't ignore those issues ;-)

Matlab's a powerful program; surely it can be told to produce its output in
UTF-8 or UTF-16...

Matlab is extremely powerful in specific directions. The documentation
for the student version I have has no hits for "UTF", "international",
and "unicode", but pages of hits for "eigen". The only hit for
"encoding" is in the Signal Processing Toolbox and "quantizes the
entries in a multidimensional array of floating-point numbers u and
encodes them as integers". "ASCII" is used in the documentation as being
the alternative to "binary".

The downloaded code that I'm using is all matrix-to-matrix internal
operations, not I/O.

I suspect the Matlab stdout and stderr are going to be predominantly in
the ASCII character set. Any non-ASCII text would have to be in the
default encoding for the platform.

Patricia

 

[Lasse Reichstein Nielsen]

The question is what replaces it, when the recommendation in the
documentation, StringReader, does not seem to do the whole job, because
there does not seem to be any way to get from there to an InputStream.

My guess is that a String should not be convertible to an InputStream
of bytes directly, because there is so many ways a String can be made
into bytes with none of them being an obvious default. I.e., asking to
go directly from a String to an InputStream was asking for something
that was better done in two separable steps: String to bytes, bytes to
stream.

Strings contain characters, so the most fitting sequential input to
convert it to would be a Reader.

/L

 

[Mike Schilling]

Matlab is extremely powerful in specific directions. The documentation
for the student version I have has no hits for "UTF", "international",
and "unicode", but pages of hits for "eigen". The only hit for
"encoding" is in the Signal Processing Toolbox and "quantizes the
entries in a multidimensional array of floating-point numbers u and
encodes them as integers". "ASCII" is used in the documentation as being
the alternative to "binary".

The downloaded code that I'm using is all matrix-to-matrix internal
operations, not I/O.

I suspect the Matlab stdout and stderr are going to be predominantly in
the ASCII character set. Any non-ASCII text would have to be in the
default encoding for the platform.

Which may or may not be the default encoding for any particular Java
installation.

I'm with Chris on this. If nothing else, specifying "US-ASCII" or
"ISO_8851_1" (or whatever) is awfully cheap documentation about what sort of
input your code expects, and will make debugging any future miscues far
eaiser for whoever's maintaining it then.

 

[Oliver Wong]

Patricia Shanahan wrote:

The solution, as Arne pointed out, is to first get a byte array from
the
String. If internationalization were an issue, I would specify an
encoding on that conversion.

I'd still specify the encoding explicitly -- you may as well be clear on
what
the test is actually testing.

BTW, I don't believe that character encodings should be thought of as
just an
internationalisation issue. (And even they if were, you -- being a
foreigner -- shouldn't ignore those issues ;-)

Matlab's a powerful program; surely it can be told to produce its output
in
UTF-8 or UTF-16...

Matlab is extremely powerful in specific directions. The documentation
for the student version I have has no hits for "UTF", "international",
and "unicode", but pages of hits for "eigen". [...]
I suspect the Matlab stdout and stderr are going to be predominantly in
the ASCII character set. Any non-ASCII text would have to be in the
default encoding for the platform.

[...]

If nothing else, specifying "US-ASCII" or "ISO_8851_1" (or whatever) is
awfully cheap documentation about what sort of input your code expects,
and will make debugging any future miscues far eaiser for whoever's
maintaining it then.

Alternatively, it might be more accurate to put a TODO with something
like:

/*TODO: I don't know what encoding MatLab actually uses. If you find out,
set it here.*/

Setting an explicit encoding (to me) implies that that's the actual
encoding you want to use, as opposed to you having just chosen an encoding
randomly because you didn't know which one was appropriate.

- Oliver

 

[Mike Schilling]

Chris Uppal wrote:
Patricia Shanahan wrote:

The solution, as Arne pointed out, is to first get a byte array from
the
String. If internationalization were an issue, I would specify an
encoding on that conversion.

I'd still specify the encoding explicitly -- you may as well be clear
on what
the test is actually testing.

BTW, I don't believe that character encodings should be thought of as
just an
internationalisation issue. (And even they if were, you -- being a
foreigner -- shouldn't ignore those issues ;-)

Matlab's a powerful program; surely it can be told to produce its
output in
UTF-8 or UTF-16...

Matlab is extremely powerful in specific directions. The documentation
for the student version I have has no hits for "UTF", "international",
and "unicode", but pages of hits for "eigen". [...]
I suspect the Matlab stdout and stderr are going to be predominantly in
the ASCII character set. Any non-ASCII text would have to be in the
default encoding for the platform.

[...]

If nothing else, specifying "US-ASCII" or "ISO_8851_1" (or whatever) is
awfully cheap documentation about what sort of input your code expects,
and will make debugging any future miscues far eaiser for whoever's
maintaining it then.

Alternatively, it might be more accurate to put a TODO with something
like:

/*TODO: I don't know what encoding MatLab actually uses. If you find out,
set it here.*/

Yes, I did mean setting it *after* finding out the correct value