«

Patricia Shanahan wrote:

> 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...

Chris Uppal wrote:
> Patricia Shanahan wrote:
>
>> 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

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 wrote:
> Arne Vajhøj wrote:
> > Patricia Shanahan wrote:
> >> 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
> >
>
> 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

vahan wrote:
> 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

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...

-- chris

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". 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

Patricia Shanahan <> writes:

> 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
--
Lasse Reichstein Nielsen -
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'

"Patricia Shanahan" <> wrote in message
newsAXIg.11588$ ink.net...
> 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". 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.

"Mike Schilling" <> wrote in message
newso%Ig.4293$ m...
>
> "Patricia Shanahan" <> wrote in message
> newsAXIg.11588$ ink.net...
>> 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.*/

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

"Oliver Wong" <> wrote in message
news:ic0Jg.22473$tP4.17596@clgrps12...
>
> "Mike Schilling" <> wrote in message
> newso%Ig.4293$ m...
>>
>> "Patricia Shanahan" <> wrote in message
>> newsAXIg.11588$ ink.net...
>>> 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