SI-8549 Enforce serialization stability for selected collections

To date, we've been hesidant to offer any guarantees about
Java serialization of standard library types among heteregenous
Scala versions.

Nonetheless, we have added `SerialVersionUID` annotations to
parts of the standard library, to offer some stability. This
protects against two winds of change: automatic calculation of
this UID might differ between JVM versions, or it might differ
due to otherwise immaterial changes to the library in Scala
releases.

With this commit, we strengthen the guarantees. Classes
marked with `SerialVersionUID` will be serialization compatible
within minor releases of Scala. This is backed up by the
enclosed test.

After major releases, we reserve the right to break this.
But the test will serve to avoid *accidental* changes.

Specifically, the test case checks:

  - deserialize(serialize(x)) == x
  - serialize(x) is stable over time

I have included values of all types marked with `@SerialVersionUID`
in the library. For some types, I've added variations in the
values to exercise different subclasses, such as `Set1` / `Set2`.

This found that that the serialized form of predefined `ClassTags`
included the cached identity hash code and failed the stability
test. This wasn't an issue for correctness as they also provide
`readResolve`, but I marked those fields as `@transient` in any
case to comply with the test expectations.

That whole area is good example of a serialization worst-practice:
using anonymous classes in code like:

    val Object: Manifest[java.lang.Object] = new PhantomManifest[...](...) {
       private def readResolve(): Any = Manifest.AnyVal
    }

... will lead to instability if these declarations are shifted around
in the file. Named classes would be preferred. I've noted this in a
TODO comment for 2.12.

0 files changed, 0 insertions, 0 deletions