Java Reference
In-Depth Information
even if they did not serialize the collections. This violates the tenet that you should never have to
pay for functionality that you don't use.
Another possible approach would be for
HashSet.readObject
to call
ObjectInputStream.registerValidation
and to delay population of the hash set until the
validateObject
callback. This approach seems more attractive in that it adds cost only to
deserialization, but it would break any code that tried to use a deserialized
HashSet
instance while
deserialization of the containing stream was still in progress.
Whether either of these approaches is practical remains to be seen. In the meantime, we must live
with the current behavior. Luckily, there is a workaround:
If a
HashSet
,
Hashtable
, or
HashMap
will be serialized, ensure that its contents do not refer back to it, directly or indirectly.
By
contents
, we mean elements, keys, and values.
There is also a lesson for developers of serializable classes:
In
readObject
or
readResolve
methods, avoid invoking methods directly or indirectly on objects currently being deserialized.
If you must violate this advice in the
readObject
or
readResolve
method for some class
C
, ensure
that no instance of
C
appears in a cycle in the graph of objects being deserialized. Unfortunately,
this is not a local property: In general, you must consider the whole system in order to verify it.
In summary, the Java serialization system is fragile. In order to serialize many classes correctly and
efficiently, you must write
readObject
or
readResolve
methods [EJ Items 55-57]. This puzzle
demonstrates that you must write these methods carefully in order to avoid corruption of
deserialized instances. The
readObject
methods of
HashSet
,
HashMap
, and
Hashtable
are
susceptible to corruption. For platform designers, if you choose to provide a serialization system, try
to design one that is not so fragile. Robust serialization systems are notoriously difficult to design.
< Day Day Up >
Search WWH ::
Custom Search