Reading and Writing Objects

Object serialization saves an object's state in a sequence of bytes so that the object can be reconstituted from those bytes at a later time. Serialization in Java was first developed for use in RMI. RMI allows an object in one virtual machine to invoke methods in an object in another virtual machine, possibly in a different computer on the other side of the planet, by sending arguments and return values across the Internet. This requires a way to convert those arguments and return values to and from byte streams. It's a trivial task for primitive data types, but you need to be able to convert objects as well. That's what object serialization provides.

Object serialization is also used in the JavaBeans component software architecture. Bean classes are loaded into visual builder tools such as NetBeans. The designer then customizes the beans by assigning fonts, sizes, text, and other properties to each bean and connects them together with events. For instance, a button bean generally has a label property that is encoded as a string of text. The designer can change this text.

Once the designer has assembled and customized the beans, the form containing all the beans must be saved. It's not enough to save the bean classes themselves; the customizations that have been applied to the beans must also be saved. That's where serialization comes in: it stores the bean as an object and thus includes any customizations, which are nothing more than the values of the bean's fields. The customized beans are stored in a .ser file, which is often placed inside a JAR archive. Thus, instead of having to write long init( ) methods that create and initialize many different components and objects, you can assemble the components in a visual tool, assign properties to them, save the whole group, and then load them back in.

Object serialization provides a predefined format you can use for saving files. For example, suppose you're writing a chess game with a Board class that stores the locations of all the pieces on the board. It's not particularly difficult to design a file format that includes the position of every piece on the board and write the code to write the current state of the board into a file. It is, however, time-consuming. With object serialization, you can write the entire board into a file with one method call. All you need to do to save a game is write the Board object onto an object output stream chained to a file output stream. To restore the game, read the Board object from an object input stream chained to a file input stream. I don't suggest using object serialization for all your file formats. For one thing, object serialization is slow and a performance bottleneck for large and complicated files. If you define your own format, you can save the minimum amount of information you need; serialization saves the entire object graph for the Board, including lots of things that aren't necessary to restore the state of the board. Furthermore, while it's quite easy to create simple systems based on object serialization in two or three lines of code, these simple systems tend to be unreliable, fragile, and insecure. Robust, reliable, secure serialization is a good deal more complex. Certainly, for small chores, though, object serialization provides a very convenient predefined file format.