Serialization « Class « Java Articles

The question refers to the following problem: when deserializing an object of class X, Java must establish that the incoming data is sufficiently compatible with the local class X definition. This is accomplished by comparing the so-called stream-unique identifiers (SUIDs) of the incoming and local class definitions. If the two SUIDs do not match, deserialization fails. If you don't do anything, the SUID is computed as a hash of various class elements: class name, implemented interfaces, declared nonstatic, nontransient fields, declared nonprivate methods, and so on. But it is also possible to take control of this value by declaring the following class field:

But what if your object contains references to other objects or is composed of other objects? No problem! The serialization mechanism automatically detects references to other objects. As long as the "sub-objects" are also serializable, ObjectOutputStream serializes them and includes them in the stream.

Editor's note: Sometimes the most interesting discussions begin when someone says, "This may be a stupid question, but ...." If the person asking the question has taken the time to think about the problem before asking, the question is often not stupid at all. The uncertainty points out an ambiguity in the specs, holes in the docs, or a search for how more experienced programmers might address a particular problem. From time to time, we will print one of the "(Not So) Stupid Questions" we receive and invite our readers to answer the question in the feedback section.

Most articles about serialization cover the basics -- essentially, what it is and how to perform the bare minimum. In actuality, the object serialization capabilities are much richer. In this article, you'll get a review of the basics of serialization, followed by explanations of validating serialized streams, manipulating serializable fields through ObjectStreamField, and encrypting object streams.

One of the most persistent problems in developing Web applications in Java is how to best handle session state. There is a balance that you must seek to maintain between storing too much session state that leads to performance problems in storing large session objects. Storing too little session state adversely affects the functionality of an application, or leads to performance problems when developers must constantly re-create the same set of objects. This is not a new problem, and the performance problems produced by storing sessions that are too large have been well documented (for example, see WebSphere Application Server Development Best Practices for Performance and Scalability). Many applications have tried to work around this by using various techniques to make the session smaller. Unfortunately, these approaches lead to solutions that are complex and force each application developer to remember what is in the HttpSession "state" and what is in some other "session." This best practice discusses using transient variables to enable WebSphere® to selectively serialize objects, thus improving performance.

In this article, you will investigate the process of serializing an object so that you can write it out to a file. Next month, you will create wrappers that will allow you to write data from a Java program using JDBC to a database (your first example will be Microsoft Access). In the process of these next few articles, you will focus on the concept of object wrappers. After you cover the topics of object serialization and connecting to a database, you will see the power of object wrappers first hand.

You almost always find bugs when testing parts of a code base that have never been tested before, and object serialization is no different. The first time I ran the test in Listing 2 it failed, as you can see from the output in Listing 3: