Serializing Objects - Beginning Java - page 560

Writing objects to file.
Polyline: (1.0,1.0) (1.0,2.0) (2.0,3.0) (-3.0,5.0) (-5.0,1.0)
(0.0,0.0)
Polyline: (1.0,1.0) (1.0,2.0) (2.0,3.0) (-3.0,5.0) (-5.0,1.0)
(0.0,0.0) (10.0,10.0)
Polyline: (1.0,1.0) (1.0,2.0) (2.0,3.0) (-3.0,5.0) (-5.0,1.0)
(0.0,0.0) (10.0,15.0)
File written.
Reading objects from the file:
Polyline: (1.0,1.0) (1.0,2.0) (2.0,3.0) (-3.0,5.0) (-5.0,1.0)
(0.0,0.0)
Polyline: (1.0,1.0) (1.0,2.0) (2.0,3.0) (-3.0,5.0) (-5.0,1.0)
(0.0,0.0) (10.0,10.0)
Polyline: (1.0,1.0) (1.0,2.0) (2.0,3.0) (-3.0,5.0) (-5.0,1.0)
(0.0,0.0) (10.0,15.0)
How It Works
In the second try block you create an ObjectOutputStream for the file, Polygons.bin , in the Begin-
ning Java Stuff directory that is in your home directory. You create objectOut from a buffered output
stream that you create from the Path object for the file. You then create three PolyLine objects and write
each of them to the file using the writeObject() method for objectOut .
You don't need to explicitly write the LinkedList and Point objects to the stream. These are part of the
PolyLine object, so they are taken care of automatically. The same goes for when you read the PolyLine
objects back. All the subsidiary objects are reconstructed automatically.
To read the file, you create an ObjectInputStream object for Polygons.bin in the third try block. You
read the objects using the readObject() method and store the references in the polylines array. After
the try block you output the objects to the standard output stream. It couldn't be simpler really, could it?
Serializing Classes Yourself
Earlier, I identified situations where the default serialization that you used in the example won't work. One
such situation occurs if your class has a superclass that is not serializable. As I said earlier, to make it pos-
sible to overcome this, the superclass must have a default constructor, and you must take care of serializing
the fields that are inherited from the superclass yourself. If the superclass does not have a default constructor
and you do not have access to the original definition of the superclass, you have a problem with no obvious
solution.
Another situation where the default serialization mechanism isn't satisfactory is where your class has
fields that don't travel well. If you use the hashCode() method that your classes inherit from Object then
the hashcode for an object is derived from its internal address. When you read the object back from a file its
address is different and therefore so is its hashcode. You may have a class with significant numbers of fields
with zero values or values such as dates and times that can be obsoleted, for example, that you might not
want to have automatically written to the file as part of an object. These are all cases where do-it-yourself
serialization is needed.
To implement and control the serialization of a class yourself, you must implement two private methods
in the class: one for input from an ObjectInputStream object and the other for output to an ObjectOut-