Modifying stream behavior
For InputStreams and OutputStreams, streams were adapted for particular needs using “decorator” subclasses of FilterInputStream and FilterOutputStream. The Reader and Writer class hierarchies continue the use of this idea—but not exactly.
In the following table, the correspondence is a rougher approximation than in the previous table. The difference is because of the class organization; although BufferedOutputStream is a subclass of FilterOutputStream, BufferedWriter is not a subclass of FilterWriter (which, even though it is abstract, has no subclasses and so appears to have been put in either as a placeholder or simply so you wouldn’t wonder where it was). However, the interfaces to the classes are quite a close match.
Filters: Java 1.0 class
|
Corresponding Java 1.1 class
|
FilterInputStream
|
FilterReader
|
FilterOutputStream
|
FilterWriter (abstract class with no subclasses)
|
BufferedInputStream
|
BufferedReader (also has readLine( ))
|
BufferedOutputStream
|
BufferedWriter
|
DataInputStream
|
Use DataInputStream (except when you need to use readLine( ), when you should use a BufferedReader)
|
PrintStream
|
PrintWriter
|
LineNumberInputStream (deprecated)
|
LineNumberReader
|
StreamTokenizer
|
StreamTokenizer (use constructor that takes a Reader instead)
|
PushBackInputStream
|
PushBackReader
|
There’s one direction that’s quite clear: Whenever you want to use readLine( ), you shouldn’t do it with a DataInputStream (this is met with a deprecation message at compile time), but instead use a BufferedReader. Other than this, DataInputStream is still a “preferred” member of the I/O library.
To make the transition to using a PrintWriter easier, it has constructors that take any OutputStream object as well as Writer objects. However, PrintWriter has no more support for formatting than PrintStream does; the interfaces are virtually the same.
The PrintWriter constructor also has an option to perform automatic flushing, which happens after every println( ) if the constructor flag is set.