What is the purpose of all these Streams?

[Alligator]

And more specifically what is the difference between an InputStream
and a BufferedInputStream?
When should I use one and when should I use the other?

And why is there besides a BufferedInputStream also a Buffered Reader?

Should one use ?? :
InputStreamReader r = new InputStreamReader( blabla.getInputStream());

or
InputStreamReader r = new InputStreamReader( new BufferedInputStream(
blabla.getInputStream()));

or
BufferedReader br = new BufferedReader( new InputStreamReader(
blabla.getInputStream()) );

or
BufferedReader br = new BufferedReader( new InputStreamReader( new
BufferedInputStream( blabla.getInputStream())));

Does the BufferedInputStream offer some advantage over a simple
InputStream?
Any enlightment upon these subjects would be very welcome ...

[Anthony Borla]

"Alligator" <pa******@postmaster.co.uk> wrote in message
news:ee**************************@posting.google.c om...

And more specifically what is the difference between an
InputStream and a BufferedInputStream?

An 'InputStream' is both a class, and a placeholder when used as a method
parameter, which means that you can pass any object created from a class
derived from this class.

A 'BufferedInputStream' is a class that extends the capabilities of of the
'InputStream' class to implement, among other things, I/O buffering.

When should I use one and when should I use the other?

When you also want an input stream to be buffered wrap it up in a
'BufferedInputStream' object.

And why is there besides a BufferedInputStream also
a Buffered Reader?

'InputStream'-based classes read 8 bit bytes, while 'Reader'-based classes
read 16 bit characters.
*** (1) ***
Should one use ?? :
InputStreamReader r =
new InputStreamReader( blabla.getInputStream());

or
*** (2) ***

InputStreamReader r =
new InputStreamReader(
new BufferedInputStream(blabla.getInputStream()));

or

*** (3) ***

BufferedReader br =
new BufferedReader(
new InputStreamReader(blabla.getInputStream()));

or
*** (4) ***

BufferedReader br =
new BufferedReader(
new InputStreamReader(
new BufferedInputStream( blabla.getInputStream())));

Number *** (3) *** if buffering is required, and number *** (1) *** if it is
not required. In general, a stream is buffered by wrapping it up inside an
object that performs this task.

Does the BufferedInputStream offer some advantage
over a simple InputStream?

It buffers it, meaning that it uses an internal storage area to hold more
data that is requested, so helping to reduce the number of low-level I/O
operations performed. The end result is faster, more efficient I/O.

Any enlightment upon these subjects would be
very welcome ...

I strongly urge you to check out the Sun tutorials on streams, located at:

http://java.sun.com/docs/books/tutor.../io/index.html

This describes the streams concept is some depth, as well as discussing all
the Java stream classes in detail, together with much sample code.

I hope this helps.

Anthony Borla

P.S.

I apologise for the brevity of my answers - I realise they are not enough to
adequately convey the ideas behind streams and stream use. I believe,
though, that you can obtain this understanding by completing the recommended
tutorial.

[DaiIchi]

On 27 Nov 2003 00:42:29 -0800, pa******@postmaster.co.uk (Alligator)
wrote:

And more specifically what is the difference between an InputStream
and a BufferedInputStream?
When should I use one and when should I use the other?
One is buffered a buffered input stream, the other one isn't. But the
BufferedInputStream is a subclass of InputStream... so anywhere that
can use an InputStream can use a BufferedInputStream.

If you think about it, a buffered stream will read a whole buffer of
information from a socket, file, serial port, etc. Then a program can
read this information from the buffer... and the buffer will
automagically refill itself as needed from the source. This is really
useful if you're trying to suck data from a source as fast as
possible... but there will be instances where you want to keep the
data in the stream, so you may not want to use a buffer to read it.

And why is there besides a BufferedInputStream also a Buffered Reader?

Basically Readers are designed for text I/O--they know how to do
things like localization (i.e., translating character sets).
BufferedInputStream is much older than the BufferedReader (having been
in Java since 1.0).
Should one use ?? :
InputStreamReader r = new InputStreamReader( blabla.getInputStream());

or
InputStreamReader r = new InputStreamReader( new BufferedInputStream(
blabla.getInputStream()));

Again, if you're looking for performance and don't care that the data
all gets read from (for example) a socket, then use the
BufferedInputStream.
or
BufferedReader br = new BufferedReader( new InputStreamReader(
blabla.getInputStream()) );

or
BufferedReader br = new BufferedReader( new InputStreamReader( new
BufferedInputStream( blabla.getInputStream())));
Hehe, good question. My answer is try and use what makes you most
comfortable. I'm not sure which one is actually more efficient. To
me, it's sort of like, which is better:
i = i + 37;
or
i += 37; ?

(answer is that efficiency-wise, it makes no difference (since the
compiler optimizes the code), but I prefer the former rather than the
latter because non-C/++/Java programmers have a better understanding
of the logic).

Does the BufferedInputStream offer some advantage over a simple
InputStream?
Any enlightment upon these subjects would be very welcome ...

[FISH]

"Anthony Borla" <aj*****@bigpond.com> wrote in message news:<XT*****************@news-server.bigpond.net.au>...

'InputStream'-based classes read 8 bit bytes, while 'Reader'-based classes
read 16 bit characters.

At the risk of nit-picking, I think this needs a bit of clarification:
The old 1.02 'stream' classes used to have methods which returned
strings of 16 bit chars - but the way they translated the bytes in
the source data to Unicode characters was too primitive. The new
'reader' classes actually know how to process Utf type data, meaning
that they can cope when they encounter chars which are outside the
usual one byte (seven bit) ASCII range.

So actually it is more accurate to say the 'reader'-based classes
read 8-or-more bit characters, translating them into 16 bit Unicode.

I strongly urge you to check out the Sun tutorials on streams, located at:

http://java.sun.com/docs/books/tutor.../io/index.html

That's good advice. I second that... :-)
-FISH- ><>

[Anthony Borla]

"FISH" <jo*****@merseymail.com> wrote in message
news:db*************************@posting.google.co m...

"Anthony Borla" <aj*****@bigpond.com> wrote in message news:<XT*****************@news-server.bigpond.net.au>...

'InputStream'-based classes read 8 bit bytes, while 'Reader'-based
classes read 16 bit characters.
At the risk of nit-picking, I think this needs a bit of
clarification: The old 1.02 'stream' classes used to
have methods which returned strings of 16 bit chars
- but the way they translated the bytes in the source
data to Unicode characters was too primitive. The
new 'reader' classes actually know how to process Utf
type data, meaning that they can cope when they
encounter chars which are outside the usual one byte
(seven bit) ASCII range.

So actually it is more accurate to say the 'reader'-based
classes read 8-or-more bit characters, translating them
into 16 bit Unicode.

Nit-pick all you want as long as it's constructive - such as in the interest
of ensuring accuracy, or perhaps just to help us all something new :) !

I strongly urge you to check out the Sun tutorials on
streams, located at:

http://java.sun.com/docs/books/tutor.../io/index.html

That's good advice. I second that... :-)

Yes, a pretty safe bet :) !

Cheers,

Anthony Borla

[Alligator]

Thank you all very much for your answers ...

The thing that conserns me most, is the possibility that I may lose
some information if I use e.g InputStream over BufferedInputStream.

As for performance, your answers made it all very clear that
BufferedInputStream is better.