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
|