Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > What replaces StringBufferInputStream

Reply
Thread Tools

What replaces StringBufferInputStream

 
 
Patricia Shanahan
Guest
Posts: n/a
 
      08-29-2006
Lasse Reichstein Nielsen wrote:
....
> Strings contain characters, so the most fitting sequential input to
> convert it to would be a Reader.


Yes, but as far as I can tell Reader is a total dead end when the
objective is InputStream.

I got stuck, and had to ask for help, precisely because I was thinking
Reader, when I should have been taking a detour through byte arrays

Patricia
 
Reply With Quote
 
 
 
 
John W. Kennedy
Guest
Posts: n/a
 
      08-30-2006
Chris Uppal wrote:
> John W. Kennedy wrote:
>
>> 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.


Only for reading and writing raw bytes. There is, so to speak, an
impedance mismatch between strings and streams, which is why, since 1.1,
strings are supposed to be processed by Reader and Writer classes.
That's why StringBufferInputStream is obsolete, producing the warning
messages that were the cause of this whole thread in the first place.

--
John W. Kennedy
"The blind rulers of Logres
Nourished the land on a fallacy of rational virtue."
-- Charles Williams. "Taliessin through Logres: Prelude"
 
Reply With Quote
 
 
 
 
=?ISO-8859-1?Q?Arne_Vajh=F8j?=
Guest
Posts: n/a
 
      08-30-2006
John W. Kennedy wrote:
> Chris Uppal wrote:
>> John W. Kennedy wrote:
>>> 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.

>
> Only for reading and writing raw bytes. There is, so to speak, an
> impedance mismatch between strings and streams, which is why, since 1.1,
> strings are supposed to be processed by Reader and Writer classes.
> That's why StringBufferInputStream is obsolete, producing the warning
> messages that were the cause of this whole thread in the first place.


Your first post said "Java doesn't want you to use an InputStream
for anything" without the "Only for reading and writing raw bytes".

Arne
 
Reply With Quote
 
M.J. Dance
Guest
Posts: n/a
 
      08-30-2006
Patricia Shanahan wrote:
> Lasse Reichstein Nielsen wrote:
> ...
>> Strings contain characters, so the most fitting sequential input to
>> convert it to would be a Reader.

>
> Yes, but as far as I can tell Reader is a total dead end when the
> objective is InputStream.
>
> I got stuck, and had to ask for help, precisely because I was thinking
> Reader, when I should have been taking a detour through byte arrays


That seems to be the problem with this input stream <-> reader (and output
stream <-> writer, for that matter) dichotomy. Every(?) reader has an uderlying
input stream which, I imagine, wouldn't be a problem to obtain. But that would
mean inviting problems: reading from both stream and reader simultaneously could
cause "unpredictable" behaviour: a few <khm/> years ago I was trying to make a
jsp serve binary content. No problem, I thought, one can obtain an output stream
from response (implicit object, instanceof (Http)ServletResponse, available in
every jsp) and send data through there. But it (the servlet engine, that is),
said that it already called .getWriter() and that .getOutputStream() cannot be
called after that. Maybe things changed since then, but it's a good
illustration. I think.
 
Reply With Quote
 
Chris Uppal
Guest
Posts: n/a
 
      08-30-2006
John W. Kennedy wrote:
> Chris Uppal wrote:
> > John W. Kennedy wrote:
> >
> > > 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.

>
> Only for reading and writing raw bytes.


?!? Only !?!

That's hardly a trivial, obscure, or unimportant application !

(In fact, judging from what I read in this ng, many applications, or would-be
applications, of Readers or Writers are technically wrong in that the posters
are trying to treat binary data as if it were "really" text.)

-- chris


 
Reply With Quote
 
Chris Uppal
Guest
Posts: n/a
 
      08-30-2006
Oliver Wong wrote:

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


Fair point.

With luck (i.e. I haven't bothered to check) the US-ASCII decoder will signal
an error if it is fed bytes outside the [0, 127] range. If so then setting
that would be one way to be explicit about the assumption (almost certainly
correct) that I think Patricia's making.

-- chris



 
Reply With Quote
 
Lasse Reichstein Nielsen
Guest
Posts: n/a
 
      08-30-2006
"M.J. Dance" <(E-Mail Removed)> writes:

> That seems to be the problem with this input stream <-> reader (and
> output stream <-> writer, for that matter) dichotomy. Every(?) reader
> has an uderlying input stream which, I imagine, wouldn't be a problem
> to obtain.


Except, e.g., StringReader.

If you are communicating between processes, or even computers, then at
some point you'll represent your data as the lowest common
denominator: bytes, but working inside a single program, you can start
out with characters and keep it that way.

There is no way to meaningfully convert a generic Writer to an
OutputStream, and it's an implementation detail whether there is an
underlying OutputStream for a given Writer, so the Writer interface
can't meaningfully expose a method for giving out an OutputStream.

On the opposite end, you shouldn't blindly convert an InputStream
to a Reader without knowing that the bytes do represent characters
in the encoding you have chosen.

/L
--
Lasse Reichstein Nielsen - http://www.velocityreviews.com/forums/(E-Mail Removed)
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'
 
Reply With Quote
 
Chris Uppal
Guest
Posts: n/a
 
      08-30-2006
Lasse Reichstein Nielsen wrote:

> There is no way to meaningfully convert a generic Writer to an
> OutputStream, and it's an implementation detail whether there is an
> underlying OutputStream for a given Writer, so the Writer interface
> can't meaningfully expose a method for giving out an OutputStream.


Certainly there is. You can create an OutputStream decorator which wraps a
Writer (or an InputStream which wraps a Reader) in just the same way as an
OutputStreamWriter wraps an OutputStream. All you need is a CharacterDecoder
(or Encoder).

The java.io package lacks such a beast, but it's trivial enough to create your
own if you have a need for it (and -- as I said before -- if you can think of
an acceptable name for it).

I admit there's not an /awful/ lot of use for it though...

-- chris



 
Reply With Quote
 
Mike Schilling
Guest
Posts: n/a
 
      08-30-2006

"Chris Uppal" <(E-Mail Removed)-THIS.org> wrote in message
news:44f550df$0$637$(E-Mail Removed)...
> Oliver Wong wrote:
>
>> 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.

>
> Fair point.
>
> With luck (i.e. I haven't bothered to check) the US-ASCII decoder will
> signal
> an error if it is fed bytes outside the [0, 127] range. If so then
> setting
> that would be one way to be explicit about the assumption (almost
> certainly
> correct) that I think Patricia's making.



Not quite so much luck.

import java.io.*;

public class BadAscii
{
public static void main(String[] args) throws Exception
{
byte arr[] = { (byte)0x40, (byte)0x80};

ByteArrayInputStream bais = new ByteArrayInputStream(arr);
InputStreamReader isr = new InputStreamReader(bais, "US-ASCII");
while (true)
{
int r = isr.read();
if (r < 0)
break;
System.out.println(
(char)r + "(" + Integer.toHexString(r) + ")");
}
}
}

results in

% java -cp . BadAscii
@(40)
?(fffd)

So, no exception, but the FFFD is a clear indication that there's been a
decoding error.


 
Reply With Quote
 
Mike Schilling
Guest
Posts: n/a
 
      08-30-2006

"Chris Uppal" <(E-Mail Removed)-THIS.org> wrote in message
news:44f578f9$0$641$(E-Mail Removed)...
>
> Certainly there is. You can create an OutputStream decorator which wraps
> a
> Writer (or an InputStream which wraps a Reader) in just the same way as an
> OutputStreamWriter wraps an OutputStream. All you need is a
> CharacterDecoder
> (or Encoder).
>
> The java.io package lacks such a beast, but it's trivial enough to create
> your
> own if you have a need for it (and -- as I said before -- if you can think
> of
> an acceptable name for it).


WriterOutputStream and ReaderInputStream will do.


 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
New Java Podcast - the Java Posse (replaces the JavaCast) Dick Wall Java 0 10-15-2005 06:12 PM
StringReader vs. StringBufferInputStream John English Java 5 10-01-2004 09:40 AM
StringBufferInputStream deprecation Silas Snider Java 2 08-25-2004 09:38 PM
what replaces #include in .Net? David ASP .Net 8 07-02-2004 04:40 PM
What replaces RMI? Robert Mazur Java 3 02-06-2004 03:07 PM



Advertisments