Java IO.pdf - Nguyen Dang Binh

Java I/O
Needless to say, this is a lot of work. You would have to define readState() and
writeState() methods for every class whose instances you wanted to serialize. Furthermore,
you would have to track where in the byte stream particular values were stored, to make sure
that you didn't accidentally read the y coordinate of one point as the x coordinate of the next.
You'd also have to make sure you could serialize the object's superclasses, if the superclass
contained a relevant state. Classes composed of other classes would cause a lot of trouble,
since you'd need to serialize each object the first object contained, then each object those
objects contained, then the objects those objects contained, and so forth. Finally, you'd need to
avoid circular references that could put you in an infinite loop.
Fortunately, Sun's done all the work for you. Java 1.1 and later virtual machines possess code
that allows them to read the nonstatic, nontransient fields of an object and write them out in a
well-specified format. All you have to do is chain object output streams to an underlying
stream where you want the object to be written and call write(); you do not have to add any
new methods. Reading objects in from an object input stream is only slightly more
complicated; as well as reading the object from the stream, you also need to cast the object to
the correct type.
11.4 Performance
Serialization is often the easiest way to save the state of your program. You simply write out
the objects you're using, then read them back in when you're ready to restore the document.
There is a downside, however. First of all, serialization is slow. If you can define a custom file
format for your application's documents, using that format will almost certainly be much
faster than object serialization.
Second, serialization can slow or prevent garbage collection. Every time an object is written
onto an object output stream, the stream holds on to a reference to the object. Then, if the
same object is written onto the same stream again, it can be replaced with a reference to its
first occurrence in the stream. However, this means that your program holds on to live
references to the objects it has written until the stream is reset or closed—which means these
objects won't be garbage-collected. The worst-case scenario is when you keep a stream open
as long as your program runs and write every object you create onto the stream. This prevents
any objects from being garbage-collected.
The easy solution is to avoid keeping a running stream of the objects you create. Instead, save
the entire state only when the entire state is available, and then close the stream immediately.
If this isn't possible, you have the option to reset the stream by invoking its reset() method:
public void reset() throws IOException
reset() flushes the ObjectOutputStream object's internal cache of the objects it has already
written so they can be garbage-collected. However, this also means that an object may be
written onto the stream more than once, so use this method with caution.
11.5 The Serializable Interface
Unlimited serialization would introduce some security problems. For one thing, it allows
unrestricted access to an object's private fields. By chaining an object output stream to a byte
241