That's a strange way to put it, but yes.

Right.  The reading from the file will be buffered.  Incidentally,
InputStreamReader will do a bit of redundant buffering to help it decode
the character stream, but that probably doesn't matter to you, and it's
unlikely to have a significant effect on performance.

That also does buffering, but of a slightly different kind.  The
previous version buffered bytes from the file, before decoding them into
characters.  This version decodes into characters, and then buffers
those decoded characters (again, there's some redundant byte-buffering
done by InputStreamReader as well).

You probably don't have a good reason to do the latter kind of
buffering.  The major reason for buffer is to avoid the costs of two
things: crossing the user/kernel boundary too often, and asking bulk-
input devices like disks to do many small I/O operations.  To best gain
that benefit, you'd want to buffer close to the FileInputStream (and
hence choose the first option).

However, the BufferedReader class also provides a convenience method,
called readLine, which returns data only up to the next EOL sequence.  
That's a feature specifically of the BufferedReader class, so if you
intend to use it, you'd need have a reference to a BufferedReader, and
hence do the latter type of buffering.

Java makes great use of the GoF "Decorator" pattern where possible, the
streaming mechanism is a great example of that... you were correct the
first time. Buffering is being provided the BufferedReader object and
does not need to be replicated in the InputStreamReader object

- perry