Archived April 1988

The Truth about Serialization

Supporting serialization in a set of JDK 1.1 classes like Swing is a big job. At first glance, it might appear that all it takes is just adding "implements java.io.Serializable" to each class. And indeed, that does work -- in the short run.

But a better long-term strategy for implementing serialization is to determine exactly what persistent state an object being serialized should have, and then to use a combination of the transient keyword and the special serialization methods readObject() and writeObject() to save and restore the object's state.

To accommodate the evolution of a class, it's also wise to make the persistent state of an object minimal and to ensure that the (possibly private) types used to encode the object's state will be around as long as the class itself. Finally, it's necessary to stabilize the type hierarchy the class lives in: Inserting a superclass or moving the class to a different package breaks serialization.

All these rules are difficult to follow if you try to mandate them far in advance of the time when the semantics of a class have stabilized. If one takes the "just add 'implements java.io.Serializable'" approach, then being backwards-compatible effectively means never removing or changing the type of any non-transient field. It's sometimes necessary to take such a shortcut when a class library is under development and changing rapidly, but it is not he best long-term strategy.

---

How Swing 1.0 handles serialization

The Swing classes have supported serialization since Swing 0.6.1. Generally speaking, while Swing was being developed and its classes were changing at a fast clip, the Swing team took the "just add 'implements java.io.Serializable'" approach to serialization because there was simply no clear alternative at the time.

Now that Swing 1.0 is released and almost all the Swing classes have become stable, it is finally possible for the Swing team to step back and take another look at the best strategies for implementing serialization what is now a library of stable classes.

In JFC 1.1 (Swing 1.0), the Swing classes will continue to support serialization in the same way they have since last October. But the serialization mechanism they have been using, and will continue to use for now, will not continue to be used in future versions of Swing. This means that serialization in Swing 1.0 will not be compatible with serialization in future Swing releases.

In the next few releases of Swing, we will migrate to our long-term serialization design. The JDK 1.1 Swing release that will also ship as part of the JDK 1.2 core (we hope to call this "Swing 1.2") will define the final backwards-compatible serialization for Swing.

---

A warning about serialization

The serialization support offered in Swing 1.0 does work -- as it has since last October -- but should be used only for short-term storage, or for RMI between Swing 1.0 clients and servers. If you archive objects using serialization in Swing 1.0, you will not be able to reload them with future releases of Swing.

In fact, you can expect the opposite -- so Swing 1.0 serialization comes with the following disclaimer:

WARNING: Serialized objects of this class will not be compatible with future Swing releases. The current serialization support is appropriate for short-term storage or RMI between Swing1.0 applications. It will not be possible to load serialized Swing1.0 objects with future releases of Swing. The JDK1.2 release of Swing will be the compatibility baseline for the serialized form of Swing objects.

You'll find the preceding warning in the class JavaDoc for all the classes that implement Swing.

All will be fine (and final) in Swing 1.2

Fortunately, all this will change in the 1.2 release of Swing. That release will contain the final revision of the serialization implementation that will be backwards-compatible with all future Swing releases.

Before adopting this approach, the Swing team looked hard at other options, such as disabling serialization, or requiring developers to enable serialization using a switch. Of all the strategies that members of the Swing team considered, they decided that the temporary strategy that they wound up adopting would cause the fewest problems for developers who were already using serialization or who would want to start using it with Swing 1.0.

So be patient for just a while longer. Swing's final serialization mechanism will be in place for Swing 1.2, and will be stable and backwards-compatible -- backwards to Swing 1.2, that is -- in all future versions.

-- Hans Muller