Typically, you read data stored in a file or you write data to a file using I/O. However, your input and output are not limited to only files. You may read data from a String object and write it to another String object. In this case, the input is a String object; the output is also a String object. You may read data from a file and write it to a String object, which will use a file as an input and a String object as an output. Many combinations for input and output are possible. Input and output do not have to be used together all the time. You may use only input in your program, such as reading the contents of a file into a Java program. You may use only output in your program, such as writing the result of a computation to a file.

The java.io and java.nio (nio stands for New I/O) packages contain Java classes that deal with I/O. The java.io package has an overwhelming number of classes to perform I/O. It makes learning Java I/O a little complex. The situation where the number of classes increases to an unmanageable extent is called a class explosion and the java.io package is a good example of that. It is no wonder that there are some books in the market that deal only with Java I/O. These books describe all Java I/O classes one by one. This chapter looks at Java I/O from a different perspective. First, you will look at the design pattern that was used to design the Java I/O classes. Once you understand the design pattern, it is easy to understand how to use those classes to perform I/O. After all, I/O is all about reading and writing data and it should not be that hard to understand! Before you start looking at the design pattern for the I/O classes, you will learn how to deal with files in the next section.

How do you refer to a file in your computer? You refer to it by its pathname. A file’s pathname is a sequence of characters by which you can identify it uniquely in a file system. A pathname consists of a file name and its unique location in the file system. For example, on a Windows platform, C:usersdummy.txt is the pathname for a file named dummy.txt, which is located in the directory named users, which in turn is located in the root directory in the C: drive. On a UNIX platform, /users/dummy is the pathname for a file named dummy, which is located in the directory named users, which in turn is located in the root directory.

A relative pathname is resolved with respect to the working directory. Suppose dummy.txt is your pathname. If the working directory is C:, this pathname points to C:dummy.txt. If the working directory is C:users, it points to C:usersdummy.txt. Note that if you specify a relative pathname for a file, it points to a different file depending on the current working directory. A pathname that starts with a root is an absolute pathname. The forward slash (/) is the root on the UNIX platform and a drive letter followed with a backslash such as A: or C: defines the root for the Windows platform.

Suppose you need to design classes for a bar that sells alcoholic drinks. The available drinks are rum, vodka, and whiskey. It also sells two drink flavorings: honey and spices. You have to design classes for a Java application so that when a customer orders a drink, the application will let the user print a receipt with the drink name and its price.

What are the things that you need to maintain in the classes to compute the price of a drink and get its name? You need to maintain the name and price of all ingredients of the drink separately. When you need to print the receipt, you will concatenate the names of all ingredients and add up the prices for all ingredients. One way to design the classes for this application would be to have a Drink class with two instance variables: name and price. There would be a class for each kind of drink; the class would inherit from the Drink class. Some of the possible classes would be as follows:

Note that we have already listed 11 classes and the list is not complete yet. Consider ordering whiskey with two servings of honey. You can see that the number of classes involved is huge. If you add some more drinks and flavorings, the classes will increase tremendously. With this class design, you will have a problem maintaining the code. If the price of honey changes, you will need to revisit every class that has honey in it and change its price. This design will produce a class explosion. Fortunately, there is a design pattern to deal with such a problem. It is called the decorator pattern. Typically, classes are organized as shown in Figure 7-1 to use the decorator pattern.

The decorator pattern requires you to have a common abstract superclass from which you inherit your concrete component classes and an abstract decorator class. Name the common superclass Component. You can use an interface instead of an abstract class. Concrete components, shown as ConcreteComponentA and ConcreteComponentB in the class diagram, are inherited from the Component class. The Decorator class is the abstract decorator class, which is inherited from the Component class. Concrete decorators, shown as ConcreteDecoratorA and ConcreteDecoratorB in the class diagram, are inherited from the Decorator class. The Decorator class keeps a reference to its superclass Component. The reference of a concrete component is passed to a concrete decorator as an argument in its constructor as follows:

When a method is called on a concrete decorator, it takes some actions and calls the method on the component it encloses. The decorator may decide to take its action before and/or after it calls the method on the component. This way, a decorator extends the functionality of a component. This pattern is called a decorator pattern because the decorator class adds functionality to (or decorates) the component it encloses. It is also known as the wrapper pattern for the same reason: it encloses (wraps) the component that it decorates.

The decorator has the same interface as the concrete components because both of them are inherited from the common superclass, Component. Therefore, you can use a Decorator object wherever a Component object is expected. Sometimes decorators add functionality by adding new methods that are not present in the component, as shown in the class diagram: newMethodB(), newMethodC() and newMethodD().

Let’s apply this discussion about the generic class diagram of the decorator pattern to model classes for your drink application. The class diagram is shown in Figure 7-2.

In the drink application, Rum, Vodka, and Whiskey are the concrete components (main drinks). Honey and Spices are the two decorators that are added to decorate (or to change the flavor) of the main drinks.

The Drink class, shown in Listing 7-7, serves as the abstract common ancestor class for the main drinks and decorators. The name and price instance variables in the Drink class hold the name and price of a drink; the class also contains the getters for these instance variables. These methods define the common interface for the main drinks as well as the flavors.

Listing 7-8 contains the code for the Rum class that inherits from the Drink class. It sets the name and price in its constructor. Listing 7-9 and Listing 7-10 list the Vodka and Whiskey classes, respectively. The three classes are similar.

The DrinkDecorator, shown in Listing 7-11, is the abstract decorator class that is inherited from the Drink class. The concrete decorators Honey and Spices inherit from the DrinkDecorator class. It has an instance variable named drink, which is of the type Drink. This instance variable represents the Drink object that a decorator will decorate. It overrides the getName() and getPrice() methods for decorators. In its getName() method, it gets the name of the drink it is decorating and appends its own name to it. This is what I mean by adding functionality to a component by a decorator. The getPrice() method works the same way. It gets the price of the drink it decorates and adds its own price to it.

Listing 7-12 lists a concrete decorator, the Honey class, which inherits from the DrinkDecorator class. It accepts a Drink object as an argument in its constructor. It requires that before you can create an object of the Honey class, you must have a Drink object. In its constructor, it sets its name, price, and the drink it will work with. It will use the getName() and getPrice() methods of its superclass DrinkDecorator class.

Listing 7-13 lists another concrete decorator, the Spices class, which is implemented the same way as the Honey class.

It is the time to see the drink application in action. Let’s order whiskey with honey. How will you construct the objects to order whiskey with honey? It’s simple. You always start by creating the concrete component. Concrete decorators are added to the concrete component. Whiskey is your concrete component and honey is your concrete decorator. You always work with the last component object you created in the series. Typically, the last component that you created is one of the concrete decorators unless you are dealing with only a concrete component.

Note that the Honey class uses the getName() method, which is implemented in the DrinkDecorator class. It will get the name of the drink, which is Whiskey in your case, and add its own name. The h.getName() method will return “Whiskey, Honey”.

The h.getPrice() method will return 1.75. It will get the price of whiskey, which is 1.5 and add the price of honey, which is 0.25.

You do not need a two-step process to create a whiskey with honey drink. You can use the following one statement to create it:

By using this coding style, you get a feeling that Honey is really enclosing (or decorating) Whiskey. You ordered a drink: whiskey with honey. Therefore, it is better to store the reference of the final drink to a Drink variable (Drink myDrink) rather than a Honey variable (Honey h). However, if the Honey class implemented some additional methods than those inherited from the Drink class and you intended to use one of those additional methods, you need to use a variable of the Honey class to store the final reference.

How would you order a drink of whiskey with two servings of honey? It’s simple. Create a Whiskey object, enclose it in a Honey object, and enclose the Honey object in another Honey object, like so:

Similarly, you can create a drink of vodka with honey and spices, and get its name and price as follows:

Sometimes reading the construction of objects based on the decorator pattern may be confusing because of several levels of object wrapping in the constructor call. You need to read the object’s constructor starting from the innermost level. The innermost level is always a concrete component and all subsequent levels will be concrete decorators. In the previous example of vodka with honey and spices, the innermost level is the creation of vodka, new Vodka(), which is wrapped in honey, new Honey(new Vodka()), which in turn is wrapped in spices, new Spices(new Honey(new Vodka())). Figure 7-3 depicts how these three objects are arranged. Listing 7-14 demonstrates how to use your drink application.

You need to consider the other aspects of the decorator pattern:

The literal meaning of the word stream is “an unbroken flow of something.” In Java I/O, a stream means an unbroken flow (or sequential flow) of data. The data in the stream could be bytes, characters, objects, etc.

A river is a stream of water where the water flows from a source to its destination in an unbroken sequence. Similarly, in Java I/O, the data flows from a source known as a data source to a destination known as a data sink. The data is read from a data source to a Java program. A Java program writes data to a data sink. The stream that connects a data source and a Java program is called an input stream. The stream that connects a Java program and a data sink is called an output stream. In a natural stream, such as a river, the source and the destination are connected through the continuous flow of water. However, in Java I/O, a Java program comes between an input stream and an output stream. Data flows from a data source through an input stream to a Java program. The data flows from the Java program through an output stream to a data sink. In other words, a Java program reads data from the input stream and writes data to the output stream. Figure 7-4 depicts the flow of data from an input stream to a Java program and from a Java program to an output stream.

To read data from a data source into a Java program, you need to perform the following steps:

To write data to a data sink from a Java program, you need to perform the following steps:

Input/output stream classes in Java are based on the decorator pattern. By now, you know that a class design based on the decorator pattern results in several small classes. So is the case with Java I/O. There are many classes involved in Java I/O. Learning each class at a time is no easy task. However, learning these classes can be made easy by comparing them with the class arrangements in the decorator pattern. I compare the Java I/O classes with the decorator pattern later. In the next two sections, you will see input/output streams in action using simple programs, which will read data from a file and write data to a file.

Figure 7-5 depicts the class diagram that includes some commonly used input stream classes. You can refer to the API documentation of the java.io package for the complete list of the input stream classes. The comments in the class diagram compare input stream classes with the classes in the decorator pattern. Notice that the class diagram for the input streams is similar to the class diagram for your drink application, which was also based on the decorator pattern. Table 7-1 compares the classes in the decorator pattern, the drink application, and the input streams.

The abstract base component is the InputStream class, which is similar to the Drink class. You have concrete component classes of FileInputStream, ByteArrayInputStream, and PipedInputStream, which are similar to the Rum, Vodka, and Whiskey classes. You have a FilterInputStream class, which is similar to the DrinkDecorator class. Notice the decorator class in the input stream family does not use the word “Decorator” in its class name; it is named as FilterInputStream instead. It is also not declared abstract as you had declared the DrinkDecorator class. Not declaring it abstract seems to be an inconsistency in the class design. You have concrete decorator classes of BufferedInputStream, DataInputStream, and PushbackInputStream, which are similar to the Honey and Spices classes in the drink application. One noticeable difference is that the ObjectInputStream class is a concrete decorator and it is inherited from the abstract component InputStream, not from the abstract decorator FilterInputStream. Note that the requirement for a concrete decorator is that it should have the abstract component class in its immediate or non-immediate superclass and it should have a constructor that accepts an abstract component as its argument. The ObjectInputStream class fulfills these requirements.

Once you understand that the class design for input streams in Java I/O is based on the decorator pattern, it should be easy to construct an input stream using these classes. The superclass InputStream contains the basic methods to read data from an input stream, which are supported by all concrete component classes as well as all concrete decorator classes. The basic operation on an input stream is to read data from it. Some important methods defined in the InputStream class are listed in Table 7-2. Note that you have already used two of these methods, read() and close(), in the SimpleFileReading class to read data from a file.

Let’s briefly discuss the four input stream concrete decorators: BufferedInputStream, PushbackInputStream, DataInputStream, and ObjectInputStream. I discuss BufferedInputStream and PushbackInputStream in this section. I discuss DataInputStream in the “Reading and Writing Primitive Data Types” section. I discuss ObjectInputStream in the “Object Serialization” section.

Figure 7-6 depicts the class diagram that includes some commonly used output stream classes. You can refer to the API documentation of the java.io package for the complete list of the output stream classes. The comments in the class diagram compare the output stream classes with the classes required to implement the decorator pattern. Notice that the class diagram for the output stream is similar to that of the input stream and the drink application.

Most of the time, if you know the name of the input stream class, you can get the corresponding output stream class by replacing the word “Input” in the class name with the word “Output.” For example, for the FileInputStream class, you have a corresponding FileOutputStream class; for the BufferedInputStream class, you have a corresponding BufferedOutputStream class, and so on. You may not find a corresponding output stream class for every input stream class; for example, PushbackInputStream class has no corresponding output stream class. You may find some new classes that are not in the input stream class hierarchy because they do not make sense while reading data; for example, you have a new concrete decorator class PrintStream in the output stream class hierarchy. Table 7-3 compares the classes in the decorator pattern, your drink application, and the output streams.

There are three important methods defined in the abstract superclass OutputStream: write(), flush(), and close(). The write() method is used to write bytes to an output stream. It has three versions that let you write one byte or multiple bytes at a time. You used it to write data to a file in the SimpleFileWriting class in Listing 7-17. The flush() method is used to flush any buffered bytes to the data sink. The close() method closes the output stream.

The technique to use concrete decorators with the concrete component classes for the output stream is the same as for the input stream classes. For example, to use the BufferedOutputStream decorator for better speed to write to a file, use the following statement:

To write data to a ByteArrayOutputStream , use the following statements:

ByteArrayOutputStream provides some important methods: reset(), size(), toString(), and writeTo(). The reset() method discards all bytes written to it; the size() method returns the number of bytes written to the stream; the toString() method returns the string representation of the bytes in the stream; the writeTo() method writes the bytes in the stream to another output stream. For example, if you have written some bytes to a ByteArrayOutputStream called baos and want to write its content to a file represented by FileOutputStream named fos, you would use the following statement:

I don’t cover any more examples of writing to an output stream in this section. You can use SimpleFileWriting class in Listing 7-17 as an example to use any other type of output stream. You can use any output stream’s concrete decorators by using them as an enclosing object for a concrete component or another concrete decorator. I discuss the DataOutputStream, ObjectOutputStream, and PrintStream classes with examples in subsequent sections.

A pipe connects an input stream and an output stream. A piped I/O is based on the producer-consumer pattern. The producer produces data and the consumer consumes the data, without caring about each other. It works similar to a physical pipe, where you inject something at one end and gather it at the other end. In a piped I/O, you create two streams representing two ends of the pipe. A PipedOutputStream object represents one end and a PipedInputStream object the other end. You connect the two ends using the connect() method on the either object. You can also connect them by passing one object to the constructor when you create another object. You can imagine the logical arrangement of a piped input stream and a piped output stream as depicted in Figure 7-7.

The following snippet of code shows two ways of creating and connecting the two ends of a pipe:

You can produce and consume data after you connect the two ends of the pipe. You produce data by using one of the write() methods of the PipedOutputStream object. Whatever you write to the piped output stream automatically becomes available to the piped input stream object for reading. You use the read() method of PipedInputStream to read data from the pipe. The piped input stream is blocked if data is not available when it attempts to read from the pipe.

Have you wondered where the data is stored when you write it to a piped output stream? Similar to a physical pipe, a piped stream has a buffer with a fixed capacity to store data between the time it is written to and read from the pipe. You can set the pipe capacity when you create it. If a pipe’s buffer is full, an attempt to write on the pipe blocks.

Listing 7-21 demonstrates how to use a piped I/O. The main() method creates and connects a piped input and a piped output stream. The piped output stream is passed to the produceData() method, producing numbers from 1 to 50. The thread sleeps for a half second after producing a number. The consumeData() method reads data from the piped input stream. I used a quick and dirty way of handling the exceptions to keep the code smaller and readable. Data is produced and read in two separate threads.

An object of the DataInputStream class is used to read values of the primitive data types in a machine-independent way from an input stream. An object of the DataOutputStream class is used to write values of the primitive data type in a machine-independent way to an output stream.

The DataInputStream class contains readXxx() methods to read a value of data type Xxx, where Xxx is a primitive data type such as int, char, etc. For example, to read an int value, it contains a readInt() method; to read a char value, it has a readChar() method, etc. It also supports reading strings using the readUTF() method.

The DataOutputStream class contains a writeXxx(Xxx value) method corresponding to each the readXxx() method of the DataInputStream class, where Xxx is a Java primitive data type. It supports writing a string to an output stream using the writeUTF(String text) method.

The DataInputStream and DataOutputStream classes are concrete decorators, which provide you a convenient way to read and write values of the primitive data types and strings using input and output streams, respectively. You must have an underlying concrete component linked to a data source or a data sink to use these classes. For example, to write values of the primitive data types to a file named primitives.dat, you construct an object of DataOutputStream as follows:

Listing 7-22 writes an int value, a double value, a boolean value, and a string to a file named primitives.dat. The file path in the output may be different when you run this program.

Listing 7-23 reads those primitive values back. Note that you must read the values in the same order using a DataInputStream as they were written using the DataOutputStream. You need to run the WritingPrimitives class before you run the ReadingPrimitives class.

You create an object using the new operator. For example, if you have a Person class that accepts a person’s name, gender, and height as arguments in its constructor, you can create a Person object as follows:

What would you do if you wanted to save the object john to a file and later restore it in memory without using the new operator again? You have not learned how to do it yet. This is the subject of the discussion in this section.

The process of converting an object in memory to a sequence of bytes and storing the sequence of bytes in a storage medium such as a file is called object serialization. You can store the sequence of bytes to permanent storage such as a file or a database. You can also transmit the sequence of bytes over a network. The process of reading the sequence of bytes produced by a serialization process and restoring the object back in memory is called object deserialization. The serialization of an object is also known as deflating or marshaling the object. The deserialization of an object is also known as inflating or unmarshaling the object. You can think of serialization as writing an object from memory to a storage medium and deserialization as reading an object into memory from a storage medium.

An object of the ObjectOutputStream class is used to serialize an object. An object of the ObjectInputStream class is used to deserialize an object. You can also use objects of these classes to serialize values of the primitive data types such as int, double, boolean, etc.

The ObjectOutputStream and ObjectInputStream classes are the concrete decorator classes for output and input streams, respectively. However, they are not inherited from their abstract decorator classes. They are inherited from their respective abstract component classes. ObjectOutputStream is inherited from OutputStream and ObjectInputStream is inherited from InputStream. This seems to be an inconsistency. However, this still fits into the decorator pattern.

Your class must implement the Serializable or Externalizable interface to be serialized or deserialized. The Serializable interface is a marker interface. If you want the objects of a Person class to be serialized, you need to declare the Person class as follows:

Implementing the Externalizable interface gives you more control in reading and writing objects from/to a stream. It inherits the Serializable interface. It is declared as follows:

The readExternal() method is called when you read an object from a stream. The writeExternal() method is called when you write an object to a stream. You have to write the logic to read and write the object’s fields inside the readExternal() and writeExternal() methods, respectively. Your class implementing the Externalizable interface looks like the following:

The keyword transient is used to declare a class’s field. As the literal meaning of the word “transient” implies, a transient field of a Serializable object is not serialized. The following code for an Employee class declares the ssn and salary fields as transient:

The transient fields of a Serializable object are not serialized when you use the writeObject() method of the ObjectOutputStream class.

Note that if your object is Externalizable, not Serializable, declaring a field transient has no effect because you control what fields are serialized in the writeExternal() method. If you want transient fields of your class to be serialized, you need to declare the class Externalizable and write the transient fields to the output stream in the writeExternal() method of your class. I don’t cover any examples of serializing transient fields because the logic is the same as shown in Listing 7-27, except that you declare some instance variables as transient and write them to the output stream in the writeExternal() method .

The following sections discuss advanced serialization techniques. They are designed for experienced developers. If you are a beginner or an intermediate level developer, you may skip the following sections; you should, however, revisit them after you gain more experience with Java I/O.

Input and output streams are byte-based streams. In this section, I discuss readers and writers, which are character-based streams . A reader is used to read character-based data from a data source. A writer is used to write character-based data to a data sink.

Figure 7-8 and Figure 7-9 show some classes, and the relationship between them, for the Reader and Writer stream families. Recall that the input and output stream class names end with the words “InputStream” and “OutputStream,” respectively. The Reader and Writer class names end with the words “Reader” and “Writer,” respectively.

Table 7-4 and Table 7-5 compare classes in byte-based and character-based input/output streams .

Some classes in the byte-based input/output streams do not have the corresponding character-based classes and vice versa. For example, reading and writing primitive data and objects are always byte-based; therefore, you do not have any classes in the reader/writer class family corresponding to the data/object input/output streams.

I discussed how to use the byte-based input/output classes in detail in the previous sections. You will find the classes in the reader/writer and the input/output categories similar. They are also based on the decorator pattern.

In the reader class hierarchy, BufferedReader , which is a concrete decorator, is directly inherited from the Reader class instead of the abstract decorator FilterReader class . In the writer class hierarchy, all concrete decorators have been inherited from the Writer class instead of the FilterWriter. No concrete decorator inherits the FilterWriter class.

The two classes, InputStreamReader and OutputStreamWriter , in the reader/writer class family provide the bridge between the byte-based and character-based streams. If you have an instance of InputStream and you want to get a Reader from it, you can get that by using the InputStreamReader class. That is, you need to use the InputStreamReader class if you have a stream that supplies bytes and you want to read characters by getting those bytes decoded into characters for you. For example, if you have an InputStream object called iso, and you want to get a Reader object instance, you can do so as follows:

Similarly, you can create a Writer object to spit out characters from a bytes-based output stream as follows, assuming that oso is an OutputStream object:

You do not have to write only a character at a time or a character array when using a writer. It has methods that let you write a String and a CharSequence object.

Let’s write another stanza from the poem Lucy by William Wordsworth to a file and read it back into the program. This time, you will use a BufferedWriter to write the text and a BufferedReader to read the text back. Here are the four lines of text in the stanza:

The text is saved in a luci4.txt file in the current directory. Listing 7-33 illustrates how to use a Writer object to write the text to this file. You may get different output when you run the program because it prints the path of the output file, which depends on the current working directory.

If you compare the code in this listing to any other listings that write data to a stream, you will not find any basic differences. The differences lie only in using classes to construct the output stream. In this case, you used the BufferedWriter and FileWriter classes to construct a Writer object. You used the append() method of the Writer class to write the strings to the file. You can use the write() method or the append() method to write a string using a Writer object. However, the append() method supports writing any CharSequence object to the stream, whereas the write() method supports writing only characters or a string. The BufferedWriter class provides a newLine() method to write a platform-specific new line to the output stream.

How would you read the text written to the file luci4.txt using a Reader object? It’s simple. Create a BufferedReader object by wrapping a FileReader object and read one line of text at a time using its readLine() method. The readLine() method considers a linefeed (' '), a carriage return (' '), and a carriage return immediately followed by a linefeed as a line terminator. It returns the text of the line excluding the line terminator. It returns null when the end of the stream is reached. The following is the snippet of code to read the text from the luci4.txt file. You can write the full program as an exercise.

Converting a byte-based stream to a character-based stream is straightforward. If you have an InputStream object, you can get a Reader object by wrapping it inside an InputStreamReader object, like so:

If you want to construct a BufferedReader object from an InputStream object, you can do that as follows:

You can construct a Writer object from an OutputStream object as follows:

Can you have your own I/O classes? The answer is yes. How difficult is it to have your own I/O classes? It is not that difficult if you understand the decorator pattern. Having your own I/O class is just a matter of adding a concrete decorator class in the I/O class hierarchy. In this section, you add a new reader class named LowerCaseReader . It will read characters from a character-based stream and convert all characters to lowercase.

The LowerCaseReader class is a concrete decorator class in the Reader class family. It should inherit from the FilterReader class. It needs to provide a constructor that will accept a Reader object .

There are two versions of the read() method in the FilterReader class to read characters from a character-based stream. You need to override just one version of the read() method as follows. All other versions of the read() method delegate the reading job to this one.

That is all it takes to have your own reader class. You can provide additional methods in your class, if needed. For example, you may want to have a readLine() method that will read a line in lowercase. Alternatively, you can also use the readLine() method of the BufferedReader class by wrapping an object of LowerCaseReader in a BufferedReader object. Using the new class is the same as using any other reader class. You can wrap a concrete reader component such as a FileReader or a concrete decorator such as a BufferedReader inside a LowerCaseReader object. Alternatively, you can wrap a LowerCaseReader object inside any other concrete reader decorator such as a BufferedReader. Listing 7-34 contains the complete code for the LowerCaseReader class.

Listing 7-35 shows how to use your new class. It reads from the file luci4.txt. It reads the file twice: the first time by using a LowerCaseReader object and the second time by wrapping a LowerCaseReader object inside a BufferedReader object. Note that while reading the licu4.txt file the second time, you are taking advantage of the readLine() method of the BufferedReader class. The luci4.txt file should exist in your current working directory. Otherwise, you will get an error when you run the test program.

A FileInputStream lets you read data from a file, whereas a FileOutputStream lets you write data to a file. A random access file is a combination of both. Using a random access file, you can read from a file as well as write to the file. Reading and writing using the file input and output streams are sequential processes. Using a random access file, you can read or write at any position within the file, hence the name random access.

An object of the RandomAccessFile class facilitates the random file access. It lets you read/write bytes and all primitive types values from/to a file. It also lets you work with strings using its readUTF() and writeUTF() methods. The RandomAccessFile class is not in the class hierarchy of the InputStream and OutputStream classes.

A random access file can be created in four different access modes. You need to provide one of the access modes in its constructor. The access mode value is a string. They are listed as follows:

A random access file has a file pointer that is advanced when you read data from it or write data to it. The file pointer is a kind of cursor where your next read or write will start. Its value indicates the distance of the cursor from the beginning of the file in byes. You can get the value of file pointer by using its getFilePointer() method. When you create an object of the RandomAccessFile class, the file pointer is set to zero, which indicates the beginning of the file. You can set the file pointer at a specific location in the file using the seek() method.

The length() method of a RandomAccessFile returns the current length of the file. You can extend or truncate a file by using its setLength() method. If you extend a file using this method, the contents of the extended portion of the file are not defined.

Reading from and writing to a random access file is performed the same way you have been reading/writing from/to any input and output streams. Listing 7-36 demonstrates the use of a random access file. When you run this program, it writes two things to a file: the file read counter, which keeps track of how many times a file has been read using this program, and a text message of "Hello World!". The program increments the counter value in the file every time it reads the file. The counter value keeps incrementing when you run this program repeatedly. You may get different output every time you run this program

After you learn about input and output streams, it is simple to write code that copies the contents of a file to another file. You need to use the byte-based input and output streams (InputStream and OutputStream objects) so that your file copy program will work on all kinds of files. The main logic in copying a file is to keep reading from the input stream until the end of file and keep writing to the output stream as data is read from the input stream. The following snippet of code shows this file-copy logic:

Starting from JDK9, you can copy the contents of a file to another file using the transferTo(OutputStream out) method of the InputStream class. The following snippet of code copies the contents of the luci1.txt file to the luci1_copy.txt file. The exception handling logic is not shown.

A standard input device is a device defined and controlled by the operating system from where your Java program may receive inputs. Similarly, the standard output and error are other operating system-defined (and controlled) devices where your program can send outputs. Typically, a keyboard is a standard input device, and a monitor acts as a standard output and a standard error device. Figure 7-10 depicts the interaction between the standard input, output, and error devices, and a Java program .

What happens when you use the following statement to print a message?

Typically, your message is printed on the console. In this case, the monitor is the standard output device and the Java program lets you send some data to the standard output device using a high-level println() method call. You saw a similar kind of println() method call in the previous section when you used the PrintStream class that is a concrete decorator class in the OutputStream class family. Java makes interacting with a standard output device on a computer easier. It creates an object of the PrintStream class and gives you access to it through a public static variable named out in the System class. Look at the code for the System class; it declares three public static variables (one for each device: standard input, output, and error) as follows:

The JVM initializes the three variables to appropriate values. You can use the System.out and System.err object references wherever you can use an OutputStream object. You can use the System.in object wherever you can use an InputStream object.

Suppose, whenever you call the System.out.println() method to print a message on the console, you want to send all messages to a file instead. You can do so very easily. After all, System.out is just a PrintStream object and you know how to create a PrintStream object using a FileOutputStream object (refer to Listing 7-20) to write to a file. The System class provides three static setter methods, setOut(), setIn(), and setErr(), to replace these three standard devices with your own devices. To redirect all standard output to a file, you need to call the setOut() method by passing a PrintStream object that represents your file. If you want to redirect the output to a file named stdout.txt in your current directory, you do so by executing the following piece of code:

Listing 7-37 demonstrates how to redirect the standard output to a file. You may get different output on the console. After you run this program, you will see the following two messages in the stdout.txt file in your current working directory:

Generally, you use System.out.println() calls to log debugging messages. Suppose you have been using this statement all over your application and it is time to deploy your application to production. If you do not take out the debugging code from your program, it will keep printing messages on the user’s console. You do not have time to go through all your code to remove the debugging code. Can you think of an easy solution? There is a simple solution to swallow all your debugging messages. You can redirect your debugging messages to a file as you did in Listing 7-37. Another solution is to create your own concrete component class in the OutputStream class family. Let’s call the new class DummyStandardOutput , as shown in Listing 7-38.

You need to inherit the DummyStandardOutput class from the OutputStream class. The only code you have to write is to override the write(int b) method and do not do anything in this method. Then, create a PrintStream object by wrapping an object of the new class and set it as the standard output using the System.setOut() method shown in Listing 7-39. If you do not want to go for a new class, you can use an anonymous class to achieve the same result, as follows:

You can use the System.in object to read data from a standard input device (usually a keyboard). You can also set the System.in object to read from any other InputStream object of your choice, such as a file. You can use the read() method of the InputStream class to read bytes from this stream. System.in.read() reads a byte at a time from the keyboard. Note that the read() method of the InputStream class blocks until data is available for reading. When a user enters data and presses the Enter key, the entered data becomes available, and the read() method returns one byte of data at a time. The last byte read will represent a new line character. When you read a new line character from the input device, you should stop further reading or the read() call will block until the user enters more data and presses the Enter key again. Listing 7-40 illustrates how to read data entered using the keyboard.

Since System.in is an instance of InputStream, you can use any concrete decorator to read data from the keyboard; for example, you can create a BufferedReader object and read data from the keyboard one line at a time as a string. Listing 7-41 illustrates how to use the System.in object with a BufferedReader. Note that this is the kind of situation when you will need to use the InputStreamReader class to get a character-based stream (BufferedReader) from a byte-based stream (System.in). The program keeps prompting the user to enter some text until the user enters Q or q to quit the program.

The standard error device (generally the console) is used to display error messages. Its use in your program is the same as a standard output device. Instead of System.out for a standard output device, Java provides another PrintStream object called System.err. You use it as follows:

Although Java gives you three objects to represent the standard input, output, and error devices, it is not easy to use them for reading numbers from the standard input. The purpose of the Console class is to make the interaction between a Java program and the console easier. I discuss the Console class in this section. I also discuss the Scanner class used for parsing the text read from the console.

The Console class is a utility class in the java.io package that gives access to the system console, if any, associated with the JVM. The console is not guaranteed to be accessible in a Java program on all machines. For example, if your Java program runs as a service, no console will be associated to the JVM and you will not have access to it either. You get the instance of the Console class by using the static console() method of the System class as follows:

The Console class contains a printf() method that displays formatted string on the console. You also have a printf() method in the PrintStream class to write the formatted data. Refer to Chapter 17 of the first volume of this series for more details on using the printf() method and how to use the Formatter class to format text, numbers, and dates.

Listing 7-42 illustrates how to use the Console class. If the console is not available, it prints a message and exits. If you run this program using an IDE such as NetBeans, the console may not be available. Try to run this program using a command prompt. The program prompts the user to enter a user name and a password. If the user enters password letmein, the program prints a message. Otherwise, it prints that the password is not valid. The program uses the readLine() method to read a line of text from the console and the readPassword() method to read the password. When the user enters a password, it is not visible; the program receives it in a character array.

If you want to read numbers from the standard input, you have to read it as a string and parse it to a number. The Scanner class in java.util package reads and parses text, based on a pattern, into primitive types and strings. The text source can be an InputStream, a file, a String object, or a Readable object. You can use a Scanner to read primitive type values from the standard input System.in. It contains many methods, which are named liked hasNextXxx() and nextXxx(), where Xxx is a data type, such as int, double, etc. The hasNextXxx() method checks if the next token from the source can be interpreted as a value of the Xxx type. The nextXxx() method returns a value of a particular data type.

Listing 7-43 illustrates how to use the Scanner class by building a trivial calculator to perform addition, subtraction, multiplication, and division.

Java has some utility classes that let you break a string into parts called tokens. A token in this context is a part of the string. You define the sequence of characters that are considered tokens by defining delimiter characters. Suppose you have a string “This is a test, which is simple”. If you define a space as a delimiter, this string contains seven tokens:

If you define a comma as a delimiter, the same string contains two tokens:

The StringTokenizer class is in the java.util package. The StreamTokenizer class is in the java.io package. A StringTokenizer lets you break a string into tokens, whereas a StreamTokenizer gives you access to the tokens in a character-based stream.

A StringTokenizer object lets you break a string into tokens based on your definition of delimiters. It returns one token at a time. You also have the ability to change the delimiter anytime. You can create a StringTokenizer by specifying the string and accepting the default delimiters, which are a space, a tab, a new line, a carriage return, and a line-feed character (" f") as follows:

You can use the hasMoreTokens() method to check if you have more tokens and the nextToken() method to get the next token from the string.

You can also use the split() method of the String class to split a string into tokens based on delimiters. The split() method accepts a regular expression as a delimiter. Listing 7-44 illustrates how to use the StringTokenizer and the split() method of the String class.

The StringTokenizer and the split() method of the String class return each token as a string. Sometimes you may want to distinguish between tokens based on their types; your string may contain comments. You can have these sophisticated features while breaking a character-based stream into tokens using the StreamTokenizer class. Listing 7-45 illustrates how to use a StreamTokenizer .

The program uses a StringReader object as the data source. You can use a FileReader object or any other Reader object as the data source. The syntax to get the tokens is not easy to use. The nextToken() method of StreamTokenizer is called repeatedly. It populates three fields of the StreamTokenizer object: ttype, sval, and nval. The ttype field indicates the type of the token that was read. The following are the four possible values for the ttype field:

If ttype is equal to TT_WORD, the string value is stored in the field sval field. If ttype is TT_NUMBER, the number value is stored in the nval field.

StreamTokenizer is a powerful class to break a stream into tokens. It creates tokens based on a predefined syntax. You can reset the entire syntax by using its resetSyntax() method. You can specify your own set of characters that can make up a word by using its wordChars() method. You can specify your custom whitespace characters using its whitespaceChars() method.

Reading data from a data source and writing data to a data sink is called input/output. A stream represents a data source or data sink for serial reading or writing. The Java I/O API contains several classes to support input and output streams. Java I/O classes are in the java.io and java.nio packages. The input/output stream classes in Java are based on the decorator pattern.

You refer to a file in your computer by its pathname. A file’s pathname is a sequence of characters by which you can identify it uniquely in a file system. A pathname consists of a file name and its unique location in the file system. An object of the File class is an abstract representation of a pathname of a file or directory in a platform-independent manner. The pathname represented by a File object may or may not exist in the file system. The File class provides several methods to work with files and directories.

Java I/O supports two types of streams: byte-based streams and character-based streams. Byte-based streams are inherited from the InputStream or OutputStream classes. Character-based stream classes are inherited from the Reader or Writer classes.

The process of converting an object in memory to a sequence of bytes and storing the sequence of bytes in a storage medium such as a file is called object serialization. The process of reading the sequence of bytes produced by a serialization process and restoring the object back in memory is called object deserialization. Java supports serialization and deserialization of object through the ObjectInputStream and ObjectOutputStream classes. An object must implement the Serializable interface to be serialized.

The Java I/O API provides the Console and Scanner classes to interact with the console.

You can use the StringTokenizer and StreamTokenizer classes to split text into tokens based on delimiters. The String class contains a convenience split() method to split a string into tokens based on a regular expression.