Some Useful Intermediate Streams

instance of FileOutputStream . We then wrap an instance of BufferedOutputStream around the instance of FileOutputStream . And finally, we wrap GZIPOutputStream around BufferedOutputStream . To see what this accomplishes, consider what happens when we start feeding data to GZIPOutputStream the outermost OutputStream . 1. writenextByte is repeatedly called on zippedDestination . 2. zippedDestination does not immediately forward the data to buffered - Destination . Instead, it compresses the data and sends the compressed version of the data to bufferedDestination using writeint value . 3. bufferedDestination does not immediately forward the data it received to destination . Instead, it puts the data in a buffer and waits until it gets a large amount of data before calling destination s writebyte[] buffer method. Eventually, when all the data has been read in, zippedDestination s close method is called. This flushes bufferedDestination , which flushes destination , causing all the data to be written out to the physical file. After that, zippedDestination is closed, which causes bufferedDestination to be closed, which then causes destination to be closed, thus freeing up scarce system resources.

1.3.2 Some Useful Intermediate Streams

I will close our discussion of streams by briefly mentioning a few of the most useful intermediate streams in the Javasoft libraries. In addition to buffering and compressing, the two most commonly used intermediate stream types are DataInputStream DataOutputStream and ObjectInputStream ObjectOutputStream . We will discuss ObjectInputStream and ObjectOutputStream extensively in Chapt er 10 . Compressing Streams DeflaterOutputStream is an abstract class intended to be the superclass of all output streams that compress data. GZIPOutputStream is the default compression class that is supplied with the JDK. Similarly, DeflaterInputStream is an abstract class which is intended to be the superclass of all input streams that read in and decompress data. Again, GZIPInputStream is the default decompression class that is supplied with the JDK. By and large, you can treat these streams like any other type of stream. There is one exception, however. DeflaterOutputStream has a nonintuitive implementation of flush . In most stream classes, flush takes all locally buffered data and commits it either to a device or to an underlying stream. Once flush is called, you are guaranteed that all data has been processed as much as possible. This is not the case with DeflaterOutputStream . DeflaterOutputStream s flush method simply calls flush on the underlying stream. Heres the actual code: public void flush throws IOException { out.flush ; } This means that any data that is locally buffered is not flushed. Thus, for example, if the string Roy Rogers compresses to 51 bits of data, the most information that could have been sent to the underlying stream is 48 bits 6 bytes. Hence, calling flush does not commit all the information; there are at least three uncommitted bits left after flush returns. To deal with this problem, DeflaterOutputStream defines a new method called finish , which commits all information to the underlying stream, but also introduces a slight inefficiency into the compression process. DataInputStream and DataOutputStream dont actually transform data that is given to them in the form of bytes. However, DataInputStream implements the DataInput interface, and DataOutputStream implements the DataOutput interface. This allows other datatypes to be read from, and written to, streams. For example, DataOutput defines the writeFloatfloat value method, which can be used to write an IEEE 754 floating-point value out to a stream. This method takes the floating point argument, converts it to a sequence of four bytes, and then writes the bytes to the underlying stream. If DataOutputStream is used to convert data for storage into an underlying stream, the data should always be read in with a DataInputStream object. This brings up an important principle: intermediate input and output streams which transform data must be used in pairs. That is, if you zip, you must unzip. If you encrypt, you must decrypt. And, if you use DataOuputStream , you must use DataInputStream . Weve only covered the basics of using streams. Thats all we need in order to understand RMI. To find out more about streams, and how to use them, either play around with the JDK™always the recommended approach™or see Java IO by Elliotte Rusty Harold OReilly.

1.4 Readers and Writers

The last topics I will touch on in this chapter are the Reader and Writer abstract classes. Readers and writers are like input streams and output streams. The primary difference lies in the fundamental datatype that is read or written; streams are byte-oriented, whereas readers and writers use characters and strings. The reason for this is internationalization. Readers and writers were designed to allow programs to use a localized character set and still have a stream-like model for communicating with external devices. As you might expect, the method definitions are quite similar to those for InputStream and OutputStream . Here are the basic methods defined in Reader : public void close public void markint readAheadLimit public boolean markSupported public int read