Before shipping 2.13.0, we should come up with a uniform approach to serialization of collections.
To date, our approach has been -
make a collection Serializable
later, remember to add @SerialVersionUID as needed
later, switch to custom serialization (writeObject or writeReplace) to avoid directly serializing the internal structure, allowing us to change internals.
We also need to use custom serialization to deal with objects whose hash code changes on deserialization. We do this in mutable.HashMap. It appears to be missing from mutable.{HashMap, ChampHashMap} at the moment.
IMO, our default approach should be serializing a tag with the collection type, collection type specific config data (e.g. loadFactor), and then the elements. Deserialization would build a new collection with these elements. Details like class Map1, or the precise field layout of HashCollisionMapNode could be changed while remaining serialization compatible.
lrytz
commented
6 years ago
Before shipping 2.13.0, we should come up with a uniform approach to serialization of collections.
To date, our approach has been -
Serializable@SerialVersionUIDas neededwriteObjectorwriteReplace) to avoid directly serializing the internal structure, allowing us to change internals.We also need to use custom serialization to deal with objects whose hash code changes on deserialization. We do this in
mutable.HashMap. It appears to be missing frommutable.{HashMap, ChampHashMap}at the moment.IMO, our default approach should be serializing a tag with the collection type, collection type specific config data (e.g.
loadFactor), and then the elements. Deserialization would build a new collection with these elements. Details likeclass Map1, or the precise field layout ofHashCollisionMapNodecould be changed while remaining serialization compatible.However, there is a gotcha with custom serialization: https://github.com/scala/bug/issues/9237
In some classloader setups, we end up trying to deserialize the elements in the wrong classloader.