Velocity Reviews - Computer Hardware Reviews

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

Reply
Thread Tools

What replaces StringBufferInputStream

 
 
Thomas Hawtin
Guest
Posts: n/a
 
      09-01-2006
Chris Uppal wrote:
>
> (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
--
Unemployed English Java programmer
http://jroller.com/page/tackline/
 
Reply With Quote
 
 
 
 
Patricia Shanahan
Guest
Posts: n/a
 
      09-01-2006
Thomas Hawtin wrote:
> Chris Uppal wrote:
>>
>> (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.


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
 
Reply With Quote
 
 
 
 
Mike Schilling
Guest
Posts: n/a
 
      09-01-2006

"Chris Uppal" <(E-Mail Removed)-THIS.org> wrote in message
news:44f7f026$0$638$(E-Mail Removed)...
> Mike Schilling wrote:
>
> [me:]
>> > > WriterOutputStream and ReaderInputStream will do.
>> >
>> > Ugh!
>> >
>> >

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


 
Reply With Quote
 
Dale King
Guest
Posts: n/a
 
      09-05-2006
M.J. Dance wrote:
> Dale King wrote:
>> M.J. Dance wrote:
>>> 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.

>>
>> The essential issue here is that Java (rightly so in my opinion)
>> associates direction with crossing the boundary between characters and
>> bytes. Going from character to bytes is only supported in the output
>> or writing direction. The implication being that conversion between
>> the two is associated with an external entity (a file, a server). The
>> assumption with Java is that once you have it as a character the
>> program itself should only deal with it as characters. It should only
>> be converted to bytes in order to send it outside of Java.
>>
>> That is a fairly resonable way to do things in my opinion. In almost
>> all cases it is correct. There are some cases where you do want to go
>> the other way, but they are rare. And if they did support it, it would
>> probably be encouraging abuse by those that try to handle text data as
>> bytes which is just wrong.

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

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

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

--
Dale King
 
Reply With Quote
 
Patricia Shanahan
Guest
Posts: n/a
 
      09-05-2006
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.

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
 
Reply With Quote
 
Dale King
Guest
Posts: n/a
 
      09-05-2006
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
 
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