Newsletter sign-up

View all newsletters

Sign up for our technology specific newsletters.

Enterprise Java

Email Address:

Do it the "Nescafe' " way -- with freeze-dried JavaBeans

How to use object serialization for bean persistence

By Mark Johnson, JavaWorld.com, 01/01/98

Up to this point in the JavaWorld column on JavaBeans, we've discussed beans from the vantage point of how they behave within a single running Java program. The JavaBeans we've discussed so far only survive as long as there's an active reference to them, and as long as the program in which they run is executing. It would, however, be very useful for a software component to be able to survive the death of the program in which it runs, to be "resurrected" and run again when that program is revitalized; or maybe we'd want the component to be able to move from machine to machine, gathering information, or performing remote services. In either case, persistence is the key.

When the last reference to a bean goes out of scope, or when the program exits, all of a bean's "state" (the values of the bean's fields) is lost forever, unless we've saved enough information about what was inside the bean to reconstruct it later. Software object persistence is nothing more than saving information about an object so that it can be recreated at a different time and/or place. Object serialization is a means of implementing persistence by converting the object's state into a stream of bytes that can later be used to reconstruct a virtually identical copy of the original object.

In this article, we're going to take a look at some of the benefits that a persistence mechanism provides to a software component framework. We'll discuss the goals of the JavaBeans persistence approach, and then go over some introductory code examples of persistent JavaBeans.

A matter of simple storage

Though object persistence may seem like a new idea to you, you're probably more familiar with it than you know. Every file on your hard drive or floppy disk can be thought of as a persistent software object of one sort or another. For example, let's say you use a text editor to create a text file. At one point in time, there was a data structure in memory on some computer that contained the characters of your document. When you gave the editor the Save As command, you were really telling the program to persist the contents of its memory to a disk file. (Thank goodness the people who design user interfaces know better than to present information to users this way -- teaching my mom to use a word processor is hard enough without having to deal with menu items like Persist Memory State!)

The next time you run the text editor and you Load a file, the program reads the information in the text file and creates a structure in memory that is identical, more or less, to what was in memory when the file was last saved. The phrase "more or less" is significant because, typically, not all of the information about a software object is saved. For example, in the text editor there may be Undo information hanging around that goes away when the editor dies. The next time you start the editor, the file contents are there, but the Undo information is off in the Big Bit Bucket in the sky.

How object persistence and serialization work

Software object persistence works in precisely the same way as our file-saving example above: A software object in an object-oriented system can be serialized, or converted into a stream of bytes, which can be used to resurrect the object at some other place and/or time. If you're the developer who wrote the text editor discussed above, you may well have organized your program so that a document is a single object, which might be a single "monolithic" object that does everything, or an aggregation of many smaller objects that perform specialized tasks. If you ask the Document object for its serialized state, it simply returns a (possibly very long) string, which you then squirrel away on disk. When the user asks that a file be opened, your program opens the file, reads the string, and hands it to the Document class (or some class that knows how to create Document objects), and, voilà ! The Document object is risen from the dead.

 

About Us | Advertise | Contact Us | Terms of Service/Privacy

Copyright, 2006-2008 Network World, Inc. All rights reserved.