Object Streams
Using a fixed-length record format is a good choice if you need to store data of the same type. However, objects that you create in an object-oriented program are rarely all of the same type. For example, you may have an array called staff that is nominally an array of Employee records but contains objects that are actually instances of a child class such as Manager. If we want to save files that contain this kind of information, we must first save the type of each object and then the data that defines the current state of the object. When we read this information back from a file, we must:
- Read the object type;
- Create a blank object of that type;
- Fill it with the data that we stored in the file.
It is entirely possible (if very tedious) to do this by hand, and in the first version of this tutorial we did exactly this. However, Oracle developed a powerful mechanism that allows this to be done with much less effort. As you will soon see, this mechanism, called object serialization, almost completely automates what was previously a very tedious process. (You will see later in this chapter where the term "serialization" comes from.)
Storing Objects of Variable Type
To save object data, you first need to open an ObjectOutputStream object:
ObjectOutputStream out = new ObjectOutputStream(new
FileOutputStream("employee.dat"));
Now, to save an object, you simply use the writeObject method of the ObjectOutputStream class as in the following fragment:
Employee harry = new Employee("Harry Hacker", 50000,
1989, 10, 1);
Manager boss = new Manager("Carl Cracker", 80000,
1987, 12, 15);
out.writeObject(harry);
out.writeObject(boss);
To read the objects back in, first get an ObjectInputStream object:
ObjectInputStream in = new ObjectInputStream(new
FileInputStream("employee.dat"));
Then, retrieve the objects in the same order in which they were written, using the readObject method.
Employee e1 = (Employee)in.readObject(); Employee e2 = (Employee)in.readObject();
When reading back objects, you must carefully keep track of the number of objects that were saved, their order, and their types. Each call to readObject reads in another object of the type Object. You, therefore, will need to cast it to its correct type. If you don't need the exact type or you don't remember it, then you can cast it to any superclass or even leave it as type Object. For example, e2 is an Employee object variable even though it actually refers to a Manager object. If you need to dynamically query the type of the object, you can use the getClass method that we described in . You can write and read only objects with the writeObject/readObject methods, not numbers. To write and read numbers, you use methods such as writeInt/readInt or writeDouble/readDouble. (The object stream classes implement the DataInput/DataOutput interfaces.) Of course, numbers inside objects (such as the salary field of an Employee object) are saved and restored automatically. Recall that, in Java, strings and arrays are objects and can, therefore, be restored with the writeObject/readObject methods. There is, however, one change you need to make to any class that you want to save and restore in an object stream. The class must implement the Serializable interface:
class Employee implements Serializable { . . . }
The Serializable interface has no methods, so you don't need to change your classes in any way. In this regard, it is similar to the Cloneable interface that we also discussed in . However, to make a class cloneable, you still had to override the clone method of the Object class. To make a class serializable, you do not need to do anything else. Why aren't all classes serializable by default? We will discuss this in the section "Security." Example 12-4 is a test program that writes an array containing two employees and one manager to disk and then restores it. Writing an array is done with a single operation:
Employee[] staff = new Employee[3]; . . . out.writeObject(staff);
Similarly, reading in the result is done with a single operation. However, we must apply a cast to the return value of the readObject method:
Employee[] newStaff = (Employee[])in.readObject();
Once the information is restored, we give each employee a 100% raise, not because we are feeling generous, but because you can then easily distinguish employee and manager objects by their different raiseSalary actions. This should convince you that we did restore the correct types.
Example ObjectFileTest.java
1. import java.io.*;
2. import java.util.*;
3.
4. class ObjectFileTest
5. {
6. public static void main(String[] args)
7. {
8. Manager boss = new Manager("Carl Cracker", 80000,
9. 1987, 12, 15);
10. boss.setBonus(5000);
11.
12. Employee[] staff = new Employee[3];
13.
14. staff[0] = boss;
15. staff[1] = new Employee("Harry Hacker", 50000,
16. 1989, 10, 1);
17. staff[2] = new Employee("Tony Tester", 40000,
18. 1990, 3, 15);
19.
20. try
21. {
22. // save all employee records to the file employee.dat
23. ObjectOutputStream out = new ObjectOutputStream(new
24. FileOutputStream("employee.dat"));
25. out.writeObject(staff);
26. out.close();
27.
28. // retrieve all records into a new array
29. ObjectInputStream in = new ObjectInputStream(new
30. FileInputStream("employee.dat"));
31. Employee[] newStaff = (Employee[])in.readObject();
32. in.close();
33.
34. // print the newly read employee records
35. for (int i = 0; i < newStaff.length; i++)
36. System.out.println(newStaff[i]);
37. }
38. catch (Exception e)
39. {
40. e.printStackTrace();
41. }
42. }
43. }
44.
45. class Employee implements Serializable
46. {
47. public Employee() {}
48.
49. public Employee(String n, double s,
50. int year, int month, int day)
51. {
52. name = n;
53. salary = s;
54. GregorianCalendar calendar
55. = new GregorianCalendar(year, month - 1, day);
56. // GregorianCalendar uses 0 = January
57. hireDay = calendar.getTime();
58. }
59.
60. public String getName()
61. {
62. return name;
63. }
64.
65. public double getSalary()
66. {
67. return salary;
68. }
69.
70. public Date getHireDay()
71. {
72. return hireDay;
73. }
74.
75. public void raiseSalary(double byPercent)
76. {
77. double raise = salary * byPercent / 100;
78. salary += raise;
79. }
80.
81. public String toString()
82. {
83. return getClass().getName()
84. + "[name=" + name
85. + ",salary=" + salary
86. + ",hireDay=" + hireDay
87. + "]";
88. }
89.
90. private String name;
91. private double salary;
92. private Date hireDay;
93. }
94.
95. class Manager extends Employee
96. {
97. /**
98. @param n the employee's name
99. @param s the salary
100. @param year the hire year
101. @param year the hire month
102. @param year the hire day
103. */
104. public Manager(String n, double s,
105. int year, int month, int day)
106. {
107. super(n, s, year, month, day);
108. bonus = 0;
109. }
110.
111. public double getSalary()
112. {
113. double baseSalary = super.getSalary();
114. return baseSalary + bonus;
115. }
116.
117. public void setBonus(double b)
118. {
119. bonus = b;
120. }
121.
122. public String toString()
123. {
124. return super.toString()
125. + "[bonus=" + bonus
126. + "]";
127. }
128.
129. private double bonus;
130. }
java.io.ObjectOutputStream 1.1
- ObjectOutputStream(OutputStream out)
creates an ObjectOutputStream so that you can write objects to the specified OutputStream.
- void writeObject(Object obj)
writes the specified object to the ObjectOutputStream. This method saves the class of the object, the signature of the class, and the values of any non-static, non-transient field of the class and its superclasses.
java.io.ObjectInputStream 1.1
- ObjectInputStream(InputStream is)
creates an ObjectInputStream to read back object information from the specified InputStream.
- Object readObject()
reads an object from the ObjectInputStream. In particular, this reads back the class of the object, the signature of the class, and the values of the nontransient and nonstatic fields of the class and all of its superclasses. It does deserializing to allow multiple object references to be recovered.
Object Serialization File Format
Object serialization saves object data in a particular file format. Of course, you can use the writeObject/readObject methods without having to know the exact sequence of bytes that represents objects in a file. Nonetheless, we found studying the data format to be extremely helpful for gaining insight into the object streaming process. We did this by looking at hex dumps of various saved object files. However, the details are somewhat technical, so feel free to skip this section if you are not interested in the implementation. Every file begins with the 2-byte "magic number"
AC ED
followed by the version number of the object serialization format, which is currently
00 05
(We will be using hexadecimal numbers throughout this section to denote bytes.) Then, it contains a sequence of objects, in the order that they were saved. String objects are saved as
| 74 | 2-byte length | CharactersFor example, the string "Harry" is saved as
74 00 05 Harry The Unicode characters of the string are saved in UTF format. When an object is saved, the class of that object must be saved as well. The class description contains
Java gets the fingerprint by:
SHA is a very fast algorithm that gives a "fingerprint" to a larger block of information. This fingerprint is always a 20-byte data packet, regardless of the size of the original data. It is created by a clever sequence of bit operations on the data that makes it essentially 100 percent certain that the fingerprint will change if the information is altered in any way. SHA is a U.S. standard, recommended by the National Institute for Science and Technology (NIST). (For more details on SHA, see, for example, Cryptography and Network Security: Principles and Practice, by William Stallings [Prentice Hall].) However, Java uses only the first 8 bytes of the SHA code as a class fingerprint. It is still very likely that the class fingerprint will change if the data fields or methods change in any way. Java can then check the class fingerprint to protect us from the following scenario: An object is saved to a disk file. Later, the designer of the class makes a change, for example, by removing a data field. Then, the old disk file is read in again. Now the data layout on the disk no longer matches the data layout in memory. If the data were read back in its old form, it could corrupt memory. Java takes great care to make such memory corruption close to impossible. Hence, it checks, using the fingerprint, that the class definition has not changed when restoring an object. It does this by comparing the fingerprint on disk with the fingerprint of the current class. Technically, as long as the data layout of a class has not changed, it ought to be safe to read objects back in. But Java is conservative and checks that the methods have not changed either. (After all, the methods describe the meaning of the stored data.) Of course, in practice, classes do evolve, and it may be necessary for a program to read in older versions of objects. We will discuss this in the section entitled "Versioning."Here is how a class identifier is stored:
The flag byte is composed of 3 bit masks, defined in java.io.ObjectStreamConstants: static final byte SC_WRITE_METHOD = 1; // class has writeObject method that writes additional data static final byte SC_SERIALIZABLE = 2; // class implements Serializable interface static final byte SC_EXTERNALIZABLE = 4; // class implements Externalizable interface We will discuss the Externalizable interface later in this chapter. Externalizable classes supply custom read and write methods that take over the output of their instance fields. The classes that we write implement the Serializable interface and will have a flag value of 02. However, the java.util.Date class is externalizable and has a flag of 03. Each data field descriptor has the format:
The type code is one of the following:
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
