Serialization of static modules does not need to contain any data

[lrytz]

Static modules get a readResolve method that returns the singleton instance, so the de-serialized object is not used. So there's no need to serialize all the fields. See also #9375.

[SethTisue]

nice catch

[lrytz]

(It was some else's 🎣 )

[SethTisue]

@lrytz I'm reassigning most 2.12.5 tickets to "Backlog", but this seems like it might be low-hanging fruit you might actually like to tackle for 2.12.5 or 2.12.6?

[szeiger]

The problem gets worse when the object contains non-serializable state or when you use serialization proxies and circular dependencies (in which case a proxy of the wrong type can leak out into other deserialization code).

There does not seem to be an easy way to avoid this problem in a generic way (i.e. in a trait which could be implemented by multiple objects). It can't extend Externalizable because an object's class does not have a public no-args constructor. It can't serialize a dummy via writeReplace because this dummy is visible to other proxies in case of circular dependencies. The only workaround I found is to implement custom serialization code in every object (and superclass with state):

  private[this] def writeObject(out: ObjectOutputStream): Unit = ()
  private[this] def readObject(in: ObjectInputStream): Unit = ()

A proper fix could consist of giving module classes a public constructor and implementing Externalizable.

[lrytz]

Hmm, I just merged scala/scala#6676 which adds a number of these overrides that @szeiger suggests above. However, reading https://docs.oracle.com/javase/8/docs/platform/serialization/spec/output.html#a861

writeObject is responsible for saving the state of the class. Either defaultWriteObject or writeFields method must be called before writing any optional data; Even if no optional data is written, defaultWriteObject or writeFields must still be invoked once.

Maybe we're fine because modules have a readResolve method that discards the deserialized object. But can we be sure?

For superclasses of modules, this is not the case; they don't have a readResolve method.