The java.io package provides an extensive library of classes for dealing with input and output. Java provides streams as a general mechanism for dealing with data I/O. Streams implement sequential access of data. There are two kinds of streams: byte streams and character streams (a.ka. binary streams and text streams, respectively). An input stream is an object that an application can use to read a sequence of data, and an output stream is an object that an application can use to write a sequence of data. An input stream acts as a source of data, and an output stream acts as a destination of data. The following entities can act as both input and output streams:

Streams can be chained with filters to provide new functionality. In addition to dealing with bytes and characters, streams are provided for input and output of Java primitive values and objects. The java.io package also provides a general interface to interact with the file system of the host platform.

The File class provides a general machine-independent interface for the file system of the underlying platform. A File object represents the pathname of a file or directory in the host file system. An application can use the functionality provided by the File class for handling files and directories in the file system. The File class is not meant for handling the contents of files. For that purpose, there are the FileInputStream and FileOutputStream classes, which are discussed later in this chapter.

The pathname for a file or directory is specified using the naming conventions of the host system. However, the File class defines platform-dependent constants that can be used to handle file and directory names in a platform-independent way:

Some examples of pathnames are:

/book/chapter1              on Unix
C:ookchapter1         on Windows
HD:book:chapter1         on Macintosh

Some examples of path lists are:

/book:/manual:/draft                       on Unix
C:ook;D:manual;A:draft       on Windows

Files and directories can be referenced using both absolute and relative pathnames, but the pathname must follow the conventions of the host platform. On Unix platforms, a pathname is absolute if its first character is the separator character. On Windows platforms, a path is absolute if the ASCII '' is the first character, or follows the volume name (e.g., C:), in a pathname. On the Macintosh, a pathname is absolute if it begins with a name followed by a colon. Java programs should not rely on system-specific pathname conventions. The File class provides facilities to construct pathnames in a platform-independent way.

The File class has various constructors for associating a file or a directory pathname to an object of the File class. Creating a File object does not mean creation of any file or directory based on the pathname specified. A File instance, called the abstract pathname, is a representation of the pathname of a file and directory. The pathname cannot be changed once the File object is created.

An object of the File class provides a handle to a file or directory in the file system, and can be used to create, rename, and delete the entry.

A File object can also be used to query the file system for information about a file or directory:

Many methods of the File class throw a SecurityException in the case of a security violation, for example if read or write access is denied. Some methods also return a boolean value to indicate whether the operation was successful.

On Unix, the name part of "/book/chapters/one" is "one".

On Windows platforms, the name part of "c:javainjavac" is "javac".

On the Macintosh, the name part of "HD:java-tools:javac" is "javac".

The strings "." and ".." generally designate the current directory and the parent directory in pathnames, respectively.

For example, if the File object represented the absolute pathname "c:ook chapter1" on Windows, this pathname would be returned by these methods. On the other hand, if the File object represented the relative pathname "..ookchapter1" and the current directory had the absolute pathname "c:documents", the pathname returned by the getPath(), getAbsolutePath(), and getCanonicalPath() methods would be "..ookchapter1", "c:documents..ookchapter1" and "c:ookchapter1", respectively.

On Unix, the parent part of "/book/chapter1" is "/book", whose parent part is "/", which in turn has no parent.

On Windows platforms, the parent part of "c:java-tools" is "c:", which in turn has no parent.

On the Macintosh, the parent part of "HD:java-tools" is "HD:", which in turn has no parent.

The following three methods can be used to query the file system about the modification time of a file or directory, determine the size (in bytes) of a file, and ascertain whether two pathnames are identical.

A File object is created using a pathname. Whether this pathname denotes an entry that actually exists in the file system can be checked using the exists() method:

Since a File object can represent a file or a directory, the following methods can be used to distinguish whether a given File object represents a file or a directory, respectively:

To check whether the specified file has write, read, or execute permissions, the following methods can be used. They throw a SecurityException if general access is not allowed, i.e., the application is not even allowed to check whether it can read, write or execute a file.

The entries in a specified directory can be obtained as an array of file names or abstract pathnames using the following list() methods. The current directory and the parent directory are excluded from the list.

The File class can be used to create files and directories. A file can be created whose pathname is specified in a File object using the following method:

A directory whose pathname is specified in a File object can be created using the following methods:

A file or a directory can be renamed, using the following method which takes the new pathname from its argument. It throws a SecurityException if access is denied.

A file or a directory can be deleted using the following method. In the case of a directory, it must be empty before it can be deleted. It throws a SecurityException if access is denied.

The class DirectoryLister in Example 11.1 lists all entries in a directory specified in the command line. If no directory is given, an error message is printed; either by the print statement at (1) or as a result of an exception at (2). In the method listDirectory(), each entry is tested to see if it exists, as shown at (3). The entry could be an alias (symbolic link in Unix or shortcut in Windows terminology) and its destination might not exist. The method determines whether the entry is a file, in which case the absolute pathname is listed, as shown at (4). In the case of a directory, an array of entry names is created, as shown at (5). For each entry in the directory, a File object is created, as shown at (6). The method listDirectory() is called recursively for each entry, as shown at (7).

The abstract classes InputStream and OutputStream are the root of the inheritance hierarchies for handling the reading and writing of bytes (Figure 11.1). Their subclasses, implementing different kinds of input and output streams, override the following methods from the InputStream and OutputStream classes to customize the reading and writing of bytes, respectively:

Read and write operations on streams are synchronous (blocking) operations, i.e., a call to a read or write method does not return before a byte has been read or written.

Many methods in the classes contained in the java.io package throw the checked IOException. A calling method must therefore either catch the exception explicitly, or specify it in a throws clause.

Table 11.1 and Table 11.2 give an overview of the byte streams. Usually an output stream has a corresponding input stream of the same type.

The classes FileInputStream and FileOutputStream define byte input and output streams that are connected to files. Data can only be read or written as a sequence of bytes.

An input stream for reading bytes can be created using the following constructors:

An output stream for writing bytes can be created using the following constructors:

The FileInputStream class provides an implementation for the read() methods in its superclass InputStream. Similarly, the FileOutputStream class provides an implementation for the write() methods in its superclass OutputStream.

Example 11.2 demonstrates usage of writing and reading bytes to and from file streams. It copies the contents of one file to another file. The input and the output file names are specified on the command line. The streams are created at (1) and(2). The input file is read one byte at a time and written straight to the output file, as shown in the try block at (3). The end of file is reached when the read() method returns the value -1. The streams are explicitly closed, as shown at (4). Note that most of the code consists of try-catch constructs to handle the various exceptions. The example could be optimized by using buffering for reading and writing several bytes at a time.

Note the methods provided for reading and writing strings. Whereas the methods readChar() and writeChar() handle a single character, the methods readLine() and writeChars() handle a string of characters. The methods readUTF() and writeUTF() also read and write characters, but use the UTF-8 character encoding. However, the recommended practice for reading and writing characters is to use character streams, called readers and writers, that are discussed in Section 11.4.

The filter streams DataOutputStream and DataInputStream implement DataOutput and DataInput interfaces, respectively, and can be used to read and write binary representations of Java primitive values to and from an underlying stream. Both the writeX() and readX() methods throw an IOException in the event of an I/O error. In particular, the readX() methods throw an EOFException (a subclass of IOEXception) if the input stream does not contain the correct number of bytes to read. Bytes can also be skipped from a DataInput stream, using the skipBytes(int n) method which skips n bytes. The following constructors can be used to set up filters for reading and writing Java primitive values, respectively, from an underlying stream:

To read the binary representation of Java primitive values from a binary file the following procedure can be used, which is also depicted in Figure 11.2.

Example 11.3 uses both procedures described above: first to write and then to read some Java primitive values to and from a file. It also checks to see if the end of the stream has been reached, signalled by an EOFException. The values are also written to the standard input stream.

Assume that the file "info.dat" exits in the current directory and has only the byte values 10, 20 and 30, stored in that order.

Which statement is true about the program?

Select the one correct answer.

(a) The program will not compile because a certain unchecked exception is not caught.

(b) The program will compile and print 10|20|30|Input error.

(c) The program will compile and print 10|20|30|End of stream.

(d) The program will compile and print 10|20|30|, and then block in order to read from the file.

(e) The program will compile and print 10|20|30|, and terminate because of an uncaught exception.

Readers use the following methods for reading Unicode characters:

Writers use the following methods for writing Unicode characters:

When writing text to a file using the default character encoding, the following four procedures for setting up a PrintWriter can be used.

Setting up a PrintWriter based on an OutputStreamWriter which is chained to a FileOutputStream (Figure 11.4a):

Setting up a PrintWriter based on a FileOutputStream (Figure 11.4b):

Setting up a PrintWriter based on a FileWriter (Figure 11.4c):

Setting up a PrintWriter, given the file name (Figure 11.4d):

The underlying OutputStreamWriter is created to write the characters to the file in the default encoding, as shown in Figure 11.4d. In this case, there is no automatic flushing.

If a specific character encoding is desired for the writer, the first procedure (Figure 11.4a) can be used, the encoding being specified for the OutputStreamWriter:

This writer will use the 8859_1 character encoding to write the characters to the file. Alternatively, we can use one of the two PrintWriter constructors that accept a character encoding:

A BufferedWriter can be also used to improve the efficiency of writing characters to the underlying stream (explained later in this subsection).

Java primitive values and objects cannot be read directly from their text representation. Characters must be read and converted to the relevant values explicitly. One common strategy is to write lines of text and tokenize the characters as they are read, a line at a time (see the subsection The java.util.Scanner Class, p. 571). Such files are usually called text files.

When reading characters from a file using the default character encoding, the following two procedures for setting up an InputStreamReader can be used.

Setting up an InputStreamReader which is chained to a FileInputStream (Figure 11.5a):

Setting up a FileReader which is a subclass of InputStreamReader (Figure 11.5b):

If a specific character encoding is desired for the reader, the first procedure must be used (Figure 11.5a), the encoding being specified for the InputStreamReader:

This reader will use the 8859_1 character encoding to read the characters from the file. A BufferedReader can also be used to improve the efficiency of reading characters from the underlying stream, as explained later in this section.

A BufferedWriter can be chained to the underlying writer by using one of the following constructors:

Characters, strings, and arrays of characters can be written using the methods for a Writer, but these now use buffering to provide efficient writing of characters. In addition, the BufferedWriter class provides the method newLine() for writing the platform-dependent line-separator.

The following code creates a PrintWriter whose output is buffered and the characters are written using the 8859_1 character encoding (Figure 11.6a):

The following code creates a PrintWriter whose output is buffered, and the characters are written using the default character encoding (Figure 11.6b):

Note that in both cases, the PrintWriter is used to write the characters. The Buffered Writer is sandwiched between the PrintWriter and the underlying OutputStream Writer.

A BufferedReader can be chained to the underlying reader by using one of the following constructors:

In addition to the methods of the Reader class, the BufferedReader class provides the method readLine() to read a line of text from the underlying reader:

The following code creates a BufferedReader that can be used to read text lines from a file, using the 8859_1 character encoding (Figure 11.7a):

The following code creates a BufferedReader that can be used to read text lines from a file, using the default character encoding (Figure 11.7b):

Note that in both cases the BufferedReader object is used to read the text lines.

In contrast to Example 11.3, which demonstrated the reading and writing of binary representations of primitive data values, Example 11.4 illustrates the reading and writing of text representations of primitive data values.

The CharEncodingDemo class in Example 11.4 writes text representations of Java primitive values, using the 8859_1 character encoding (Figure 11.6a). The PrintWriter is buffered. Its underlying writer uses the specified encoding, as shown at (1). Values are written out with the text representation of one value on each line, as shown at (2), and the writer is closed, as shown at (3). The example uses the same character encoding to read the text file. A BufferedReader is created (Figure 11.7a). Its underlying reader uses the specified encoding, as shown at (4). The text representation of the values is read in the same order the values were written out, one value per line. The characters in the line are explicitly converted to an appropriate type of value, as shown at (5). An alternate approach to extracting values from a text line is to use a scanner (p. 571).

We check for the end of the stream at (6), which is signalled by the null value returned by the readLine() method of the BufferedReader class. The BufferedReader is closed, as shown at (7), and the values are echoed on the standard output stream, as shown at (8). Note the exceptions that are specified in the throws clause of the main() method.

The standard output stream (usually the display) is represented by the PrintStream object System.out. The standard input stream (usually the keyboard) is represented by the InputStream object System.in. In other words, it is a byte input stream. The standard error stream (also usually the display) is represented by System.err which is another object of the PrintStream class. The PrintStream class offers print() methods which act as corresponding print() methods from the PrintWriter class. These methods can be used to write output to System.out and System.err. In other words, both System.out and System.err act like PrintWriter, but in addition they have write() methods for writing bytes.

In order to read characters typed by the user, the Console class is recommended (see the next section).

A console is a unique character-based device associated with a JVM. Whether a JVM has a console depends on the platform, and also on the manner in which the JVM is invoked. When the JVM is started from a command line, and the standard input and output streams have not been redirected, the console will normally correspond to the keyboard and the display (Figure 11.8). In any case, the console will be represented by an instance of the class Console. This Console instance is obtained by calling the static method console() of the System class. If there is no console associated with the JVM, the null value is returned by this method.

The readLine() method first prints the formatted prompt on the console, and then returns the characters typed at the console when the line is terminated by the ENTER key.

• Prompt and read passwords without echoing the characters on the console.

The readPassword() method first prints the formatted prompt, and returns the password characters typed by the user in an array of char when the line is terminated by the ENTER key. The password characters are not echoed on the display.

Since a password is sensitive data, the recommended practice is to have it stored in memory only as long as it is necessary and to zero-fill the char array as soon as possible in order to overwrite the password characters.

• Print formatted strings to the console.

The Console class provides the format() and the printf() methods for this purpose. Using these methods and creating formatted strings are covered in Section 12.7, p. 593.

Note that the console only returns character-based input. For reading other types of values from the standard input stream, the Scanner class (p. 571) can be considered.

The Console class provides methods for formatted prompting and reading from the console, and obtaining the reader associated with it.

The first method reads a single line of text from the console. The second method prints a formatted prompt first, then reads a single line of text from the console. The prompt is constructed by formatting the specified args according to the specified format.

The first method reads a password or a password phrase from the console with echoing disabled. The second method does the same, but first prints a formatted prompt.

This retrieves the unique Reader object associated with this console.

The Console class provides the following methods for writing formatted strings to the console, and obtaining the writer associated with it:

The method retrieves the unique PrintWriter object associated with this console.

This method flushes the console and forces any buffered output to be written immediately.

Example 11.5 illustrates a typical use of the Console class to change the password of a user. A password file can first be generated by running the program in the class MakePasswordFile. Each user name (String) and the hash value (int) of the corresponding password are stored on a single line in a text file, separated by a space. At the start of the program, this information is read into a map declared at (1) by the method readPWStore() declared at (9). This method uses a BufferedReader chained to a FileReader to read the lines in the text file. The login name and the password hash values are extracted using a Scanner and put into the password map.

At the end of the program, the updated password map is written back to the file at (6) by the method writePWStore() declared at (10). This method uses a PrintWriter chained to a FileWriter to write the information. It uses the printf() method of the PrintWriter to format the login/password information on each line that is written to the file.

The console is obtained at (2). The login name and the current password are read at (4) by calling the readLine() and the readPassword() methods, respectively:

User verification is done by the verifyPassword() method at (7). The char array is first converted to a string by calling the String.copyValueOf() method. The hash value of this string is compared with the hash code of the password for the user looked up in the password map.

The code at (5) implements the procedure for changing the password. The user is asked to submit the new password, and then asked to confirm it. Note the password characters are not echoed. The respective char arrays returned with this input are compared for equality by the static method equals() in the java.util.Arrays class, that compares two arrays. The password is changed by the changePassword() method at (8). This puts a new entry in the password map, whose value is the hash value of the new password.

The char arrays with the passwords are zero-filled by calling the Arrays.fill() method when they are no longer needed.

11.13 Which of these are valid parameter types for the write() methods of the Writer class?

Select the three correct answers.

(a) String

(b) char

(c) char[]

(d) int

11.14 What is the default encoding for an OutputStreamWriter?

Select the one correct answer.

(a) 8859_1

(b) UTF8

(c) Unicode

(d) The default is system-dependent.

(e) The default is not system-dependent, but is none of the above.

11.15 Which of these integer types do not have their own print() method in the PrintWriter class?

Select the one correct answer.

(a) byte

(b) char

(c) int

(d) long

(e) All have their own print() method.

11.16 How can one access the standard error stream?

Select the one correct answer.

(a) It is accessed via a member of the System.err class.

(b) It is accessed via the static variable named out in the System class.

(c) It is accessed via the static variable named err in the System class.

(d) It is accessed via the static variable named err in the Runtime class.

(e) It is returned by a method in the System class.

11.17 How can we programmatically guarantee that a call to a print() method of the PrintWriter class was successful or not?

Select the one correct answer.

(a) Check if the return value from the call is -1.

(b) Check if the return value from the call is null.

(c) Catch the IOException that is thrown when an I/O error occurs.

(d) Call the checkError() method of the PrinterWriter class immediately after the print() method call returns to see if an IOException was thrown.

11.18 Given the following program:

Select the three correct answers.

(a) FileOutputStream fos = new FileOutputStream(fileName);

(b) OutputStreamWriter stream = new OutputStreamWriter(fos);

(c) FileOutputStream fos = new FileOutputStream(fileName);

(d) InputStreamWriter stream = new InputStreamWriter(fos);

(e) FileOutputStream stream = new FileOutputStream(fileName);

(f) PrintWriter stream = new PrintWriter(fileName);

(g) FileWriter stream = new FileWriter(fileName);

11.20 Given the following program:

Assume that the file "greeting.txt" exists in the current directory, has the required access permissions, and contains the following two lines of text:

Which statement is true about the program?

Select the one correct answer.

(a) The program will not compile because the FileNotFoundException is not caught.

(b) The program will compile, print Hello|Howdy|null|, and then terminate normally.

(c) The program will compile and print Hello|Howdy|Input error.

(d) The program will compile and print Hello|Howdy|End of stream.

(e) The program will compile, print Hello|Howdy|, and then block in order to read from the file.

(f) The program will compile, print Hello|Howdy|, and terminate because of an uncaught exception.

11.21 Given the following program:

Assume that the user types the strings "java dude" and "fort knox" when prompted for the user name and the password, respectively.

Which statement about the program is true?

Select the one correct answer.

(a) The program will print:

(b) The program will print:

(c) The program will print:

(d) The program will print:

Object serialization allows an object to be transformed into a sequence of bytes that can later be re-created (deserialized) into the original object. After deserialization, the object has the same state as it had when it was serialized, barring any data members that were not serializable. This mechanism is generally known as persistence. Java provides this facility through the ObjectInput and ObjectOutput interfaces, which allow the reading and writing of objects from and to streams. These two interfaces extend the DataInput and DataOutput interfaces, respectively (see Figure 11.1, p. 476).

The ObjectOutputStream class and the ObjectInputStream class implement the ObjectOutput interface and the ObjectInput interface, respectively, providing methods to write and read binary representation of objects as well as Java primitive values. Figure 11.9 gives an overview of how these classes can be chained to underlying streams and some selected methods they provide. The figure does not show the methods inherited from the abstract OutputStream and InputStream superclasses.

The read and write methods in the two classes can throw an IOException, and the read methods will throw an EOFException if the end of the stream has been reached.

The class ObjectOutputStream can write objects to any stream that is a subclass of the OutputStream, e.g., to a file or a network connection (socket). An Object OutputStream must be chained to an OutputStream using the following constructor:

For example, in order to store objects in a file and thus provide persistent storage for objects, an ObjectOutputStream can be chained to a FileOutputStream:

Objects can be written to the stream using the writeObject() method of the ObjectOutputStream class:

The writeObject() method can be used to write any object to a stream, including strings and arrays, as long as the object implements the java.io.Serializable interface, which is a marker interface with no methods. The String class, the primitive wrapper classes and all array types implement the Serializable interface. A serializable object can be any compound object containing references to other objects, and all constituent objects that are serializable are serialized recursively when the compound object is written out. This is true even if there are cyclic references between the objects. Each object is written out only once during serialization. The following information is included when an object is serialized:

An exception of the type java.io.NotSerializableException is thrown if a non-serializable object is encountered during the serialization process. Note also that objects of subclasses that extend a serializable class are always serializable.

An ObjectInputStream is used to restore (deserialize) objects that have previously been serialized using an ObjectOutputStream. An ObjectInputStream must be chained to an InputStream, using the following constructor:

For example, in order to restore objects from a file, an ObjectInputStream can be chained to a FileInputStream:

The method readObject() of the ObjectInputStream class is used to read an object from the stream:

Note that the reference returned is of type Object regardless of the actual type of the retrieved object, and can be cast to the desired type. Objects and values must be read in the same order as when they were serialized.

Serializable, non-transient data members of an object, including those data members that are inherited, are restored to the values they had at the time of serialization. For compound objects containing references to other objects, the constituent objects are read to re-create the whole object structure. In order to deserialize objects, the appropriate classes must be available at runtime. Note that new objects are created during deserialization, so that no existing objects are overwritten.

The class ObjectSerializationDemo in Example 11.6 serializes some objects in the writeData() method at (1), and then deserializes them in the readData() method at(2). The readData() method also writes the data to the standard output stream.

The writeData() method writes the following values to the output stream: an array of strings (strArray), a long value (num), an array of int values (intArray), and lastly a String object (commonStr) which is shared with the array of strings, strArray. However, this shared String object is actually only serialized once. Duplication is automatically avoided when the same object is serialized several times. Note that the array elements and the characters in a String object are not written out explicitly one by one. It is enough to pass the object reference in the writeObject() method call. The method also recursively goes through the array of strings, strArray, serializing each String object in the array.

The method readData() deserializes the data in the order in which it was written. An explicit cast is needed to convert the reference of a deserialized object to a subtype. Note that new objects are created by the readObject() method, and that an object created during the deserialization process has the same state as the object that was serialized.

Example 11.7 illustrates some salient aspects of serialization. The setup comprises the classes Wheel and Unicycle, and their client class SerialClient. The class Unicycle has a field of type Wheel, and the class Wheel has a field of type int. The class SerialClient provides two methods, writeData() and readData(), declared at (4) and (5), respectively. The writeData() method serializes a unicycle with a wheel of size 65 to a file. The readData() method deserializes the bytes on the file. The state of the objects is printed to the standard output stream before serialization, and so is the state of the object created by deserialization.

If we run the program with the following declarations for the Wheel and the Unicycle classes, where both classes are serializable:

we get the following output, showing that both serialization and deserialization were successful:

If we make the wheel field of the Unicycle class transient, (3a):

we get the following output, showing that the wheel field of the Unicycle object was not serialized:

As noted earlier, static fields are not serialized, as these are not part of the state of an object.

If the class Wheel in Example 11.7 is not serializable, (1a):

we get the following output when we run the program, i.e., a Unicycle object cannot be serialized because its constituent Wheel object is not serializable:

As we have seen, the class of the object must implement the Serializable interface if we want the object to be serialized. If this object is a compound object, then all its constituent objects must also be serializable, and so on.

It is not always possible for a client to declare that a class is Serializable. It might be declared final, and therefore not extendable. The client might not have access to the code, or extending this class with a serializable subclass might not be an option. Java provides a customizable solution for serializing objects in such cases.

The basic idea behind the scheme is to use default serialization as much as possible, and provide “hooks” in the code for the serialization mechanism to call specific methods to deal with objects or values that should not or cannot be serialized by the default methods of the object streams.

Customizing serialization is illustrated in Example 11.8. The serializable class Unicycle would like to use the Wheel class, but this class is not serializable. If the wheel field in the Unicycle class is declared to be transient, it will be ignored by the default serialization procedure. This is not a viable option, as the unicycle will be missing the wheel size when a serialized unicycle is deserialized, as was illustrated in Example 11.7.

Any serializable object has the option of customizing its own serialization if it implements the following pair of methods:

These methods are not part of any interface. Although private, these methods can be called by the JVM. The first method is called on the object when its serialization starts. The serialization procedure uses the reference value of the object passed in the ObjectOutputStream.writeObject() method to call the first method on this object. The second method is called on the object created when the deserialization procedure is initiated by the call to the ObjectInputStream.readObject() method.

Customizing serialization for objects of the class Unicycle in Example 11.8 is achieved by the methods at (3b) and (3c). Note that the field wheel is declared transient at (3a) and excluded by the normal serialization process.

In the method writeObject() at (3b), the pertinent lines of code are the following:

The call to the defaultWriteObject() method of the ObjectOutputStream does what its name implies: normal serialization of the current object. The second line of code does the customization: it writes the binary int value of the wheel size to the ObjectOutputStream. Code for customization can be called both before and after the call to the defaultWriteObject() method, as long as the same order is used during deserialization.

In the method readObject() at (3c), the pertinent lines of code are the following:

The call to the defaultReadObject() method of the ObjectInputStream does what its name implies: normal deserialization of the current object. The second line of code reads the binary int value of the wheel size from the ObjectInputStream. The third line of code creates a Wheel object passing this value in the constructor call, and assigns its reference value to the wheel field of the current object. Again, code for customization can be called both before and after the call to the defaultReadObject() method, as long as it is in correspondence with the customization code in the writeObject() method.

The client class SerialClient in Example 11.8 is the same as the one in Example 11.7. The output from the program confirms that the object state prior to serialization is identical to the object state after deserialization.

The inheritance hierarchy of an object also determines what its state will be after it is deserialized. An object will have the same state at deserialization as it had at the time it was serialized if all its superclasses are also serializable. This is because the normal object creation procedure using constructors is not run during deserialization (see Section 9.11, p. 416, on constructing the initial object state).

However, if any superclass of an object is not serializable, then the normal creation procedure using constructors is run, starting at the first non-serializable superclass, all the way up to the Object class. This means that the state at deserialization might not be the same as at the time the object was serialized, because superconstructors run during deserialization may have initialized the object’s state.

Example 11.9 illustrates how inheritance affects serialization. The Student class is a subclass of the Person class. Whether the superclass Person is serializable or not has implications for serializing objects of the Student subclass, in particular, when their byte representation is deserialized.

The following code in the method writeData() declared at (1) in the class Serial-Inheritance serializes a Student object:

The corresponding code for deserialization is in the method readData() declared at (2) in the class SerialInheritance:

We get the following output from the program in Example 11.9 when it is run with (1a) in the Person class and the Student class, i.e., when the superclass is serializable and so is the subclass, by virtue of inheritance. The results show that the object state prior to serialization is identical to the object state after deserialization. In this case, no superclass constructors were run during deserialization.

However, this is not the case when the superclass Person is not serializable. We get the following output from the program in Example 11.9 when it is run with (1b) in the Person class and the Student class, i.e. when only the subclass is serializable, but not the superclass. The output shows that the object state prior to serialization is not identical to the object state after deserialization.

During deserialization, the default constructor of the Person superclass at (2) is run. As we can see from the declaration of the Person class in Example 11.9, this default constructor does not initialize the name field, which remains initialized with the default value for reference types, i.e., null.

11.22  How many methods are defined in the Serializable interface?

           Select the one correct answer.

(a) None

(b) One

(c) Two

(d) Three

(e) None of the above.

11.23   Which of the following best describes the data written by an ObjectOutputStream?

           Select the one correct answer.

(a) Bytes and other Java primitive types.

(b) Object hierarchies.

(c) Object hierarchies and Java primitive types.

(d) Single objects.

(e) Single objects and Java primitive types.

11.24   Given the following code:

Which statement about the program is true?

Select the one correct answer.

(a) It fails to compile.

(b) It compiles, but throws an exception at runtime.

(c) It prints (Aesop, 100)(Aesop, 100).

(d) It prints (Aesop, 100)(null, 100).

(e) It prints (Aesop, 100)( , 100).

11.25   Given the following code:

Which statement about the program is true?

Select the one correct answer.

(a) It fails to compile.

(b) It compiles, but throws an exception at runtime.

(c) It prints (Aesop, 100)(Aesop, 100).

(d) It prints (Aesop, 100)(null, 100).

(e) It prints (Aesop, 100)(NoName, 100).

11.26   Given the following code:

Which statement about the program is true?

Select the one correct answer.

(a) It fails to compile.

(b) It compiles, but throws an exception at runtime.

(c) It prints (Aesop, 100)(Aesop, 100).

(d) It prints (Aesop, 100)(null, 100).

(e) It prints (Aesop, 100)(NoName, 100).

11.27   Given the following code:

Which statement about the program is true?

Select the one correct answer.

(a) It fails to compile.

(b) It compiles, but throws an exception at runtime.

(c) It prints (Aesop, 100)(Aesop, 100).

(d) It prints (Aesop, 100)(null, 100).

(e) It prints (Aesop, 100)(NoName, 100).

11.28   Given the following code:

Which statement about the program is true?

Select the one correct answer.

(a) It fails to compile.

(b) It compiles, but throws an exception at runtime.

(c) It prints (Aesop, 100)(Aesop, 100).

(d) It prints (Aesop, 100)(NewName, 100).

(e) It prints (Aesop, 100)(NoName, 100).

11.29   Given the following code:

Which statement about the program is true?

Select the one correct answer.

(a) It fails to compile.

(b) It compiles, but throws an exception at runtime.

(c) It prints (Aesop, 100, 1)(Aesop, 100, 1).

(d) It prints (Aesop, 100, 1)(NewName, 0, 1).

(e) It prints (Aesop, 100, 1)(NewName, 200, 2).

11.30   Given the following code:

Which statement about the program is true?

Select the one correct answer.

(a) It fails to compile.

(b) It compiles, but throws an exception at runtime.

(c) It prints (Aesop, 100, 1)(Aesop, 100, 1).

(d) It prints (Aesop, 100, 1)(null, 100, 2).

(e) It prints (Aesop, 100, 1)(null, 100, 1).

The following information was included in this chapter:

11.1   Write a program that reads text from a source using one encoding, and writes the text to a destination using another encoding. The program should have four optional arguments:

Use buffering, and read and write 512 bytes at a time to make the program efficient.

Errors should be written to the standard error stream.