investigate possible serialization regression(s) in 2.13 milestones

[SethTisue]

• Serialization in 2.13.0-M5 scala-xml#254
• support Scala 2.13.0-M5 (and drop M4) typelevel/scalacheck#427 (comment)

[SethTisue]

@kailuowang did cats hit something in this area, or am I misremembering?
@xuwei-k are you aware of any other repos that hit issues in this area?

[kailuowang]

@SethTisue I am sorry I don't quite remember either, I quickly checked the PR I added 2.13 support for cats and didn't find any mention of serialization.

[milessabin]

There was an issue with shapeless which I worked around by suppressing a couple of tests.

See discussion here: scala/scala#6729 (comment).

[SethTisue]

for any given project, it's useful to know whether the problem goes away with set fork in Test := true or not (see comments on the ScalaCheck ticket)

[xuwei-k]

I think these are different problems (scala/scala-xml#254, typelevel/scalacheck#427 (comment))

see my reproduce example scala/scala-xml#254 (comment). scala-xml test fail whether fork is true or false.

[SethTisue]

@kailuowang found it! typelevel/cats#2360

[ashawley]

Looks like that is the community build showing the ScalaCheck bug, but in Cats's test suite?

[eed3si9n]

It's not mentioned yet here so I'll link to an existing issue surrounding Java serialization, List, and sbt's layered class loader - scala/bug#9237 (SI-9237) "Can't deserialize scala.List[M] if scala-library is not in the same classloader as M" (see also https://bugs.openjdk.java.net/browse/JDK-4340158 and sbt/sbt#89)

@retronym foretold this in scala/collection-strawman#523:

However, there is a gotcha with custom serialization: scala/bug#9237

In some classloader setups, we end up trying to deserialize the elements in the wrong classloader.

Here's the reproduction of scala/bug#9237 modified to Scala 2.13.0-M5 and JUnit: https://github.com/eed3si9n/minimized-list-serialization/blob/v0.1.0/src/test/scala/issue/IssueTest.scala

running test from sbt should produce:

[debug] Test issue.IssueTest.testSerialization started
[error] Test issue.IssueTest.testSerialization failed: java.lang.ClassNotFoundException: issue.Meh, took 0.027 sec
[error]     at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
[error]     at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
[error]     at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
[error]     at java.lang.Class.forName0(Native Method)
[error]     at java.lang.Class.forName(Class.java:348)
[error]     at java.io.ObjectInputStream.resolveClass(ObjectInputStream.java:686)
[error]     at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1866)
[error]     at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1749)
[error]     at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2040)
[error]     at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1571)
[error]     at java.io.ObjectInputStream.readObject(ObjectInputStream.java:431)
[error]     at scala.collection.generic.DefaultSerializationProxy.readObject(DefaultSerializationProxy.scala:46)
[error]     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[error]     at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
[error]     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[error]     at java.lang.reflect.Method.invoke(Method.java:498)
[error]     at java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:1158)
[error]     at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:2176)
[error]     at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2067)
[error]     at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1571)
[error]     at java.io.ObjectInputStream.readObject(ObjectInputStream.java:431)
[error]     at issue.IssueTest.deserialize(IssueTest.scala:25)
[error]     at issue.IssueTest.testSerialization(IssueTest.scala:11)

This is caused by ObjectInputStream not handling layered class loaders, which explains why it often goes away if you fork the test.

workaround 1: fork the test and/or run

If you use Java serialization, fork your test.

Test / fork := true

Would that work?

workaround 2: custom ObjectInputStream

As a workaround, when possible you can use a custom ObjectInputStream. Here's something I implemented as a demonstration: https://github.com/eed3si9n/minimized-list-serialization/blob/v0.2.0/src/main/scala/issue/ScalaObjectInputStream.scala

Using that deserialize would look like this:

  def deserialize[A <: Serializable: ClassTag](bytes: Array[Byte]): A = {
    val s = new ByteArrayInputStream(bytes)
    val is = ScalaObjectInputStream[A](s)
    is.readObject
  }

If your code is the one calling the deserialization that might be ok, but I'm guessing that's not always the case.

workaround 3: provide alternative class loader for sbt

The other workaround might be to provide an alternative flatter class loader for sbt.
At that point, however, might as well just use forked run. I guess it depends on how often Java serialization is used in the wild.

[eed3si9n]

About the other issue reported by Yoshida-san. To minimize scala.xml.XMLTestJVM.serializeAttribute failure he created a minimization using a custom collection that looks like this:

class MyCollection[B](val list: List[B]) extends scala.collection.Iterable[B] {
  override def iterator = list.iterator
  // protected[this] override def writeReplace(): AnyRef = this
}

I'm breaking up the test into the following steps:

  @Test
  def testMyCollection: Unit = {
    val list = List(1, 2, 3)
    val arr = serialize(new MyCollection(list))
    val obj2 = deserialize[MyCollection[Int]](arr)
    assert(obj2.list == list)
  }

When I run this the error I get is as follows:

[error] Test issue.IssueTest.testMyCollection failed: java.lang.ClassCastException: scala.collection.immutable.$colon$colon cannot be cast to issue.MyCollection, took 0.01 sec
[error]     at issue.IssueTest.testMyCollection(IssueTest.scala:20)
[error]     ...

In other words, I don't get to the assertion, but instead it's failing at casting in the deserialization which deserialized $colon$colon instead of MyCollection. This looks to be a different problem than scala/bug#9237.

what's going on?

scala/scala#6676 makes Iterable Serializable by default.

trait Iterable[+A] extends IterableOnce[A] with IterableOps[A, Iterable, Iterable[A]] with Serializable {

with writeReplace implemented as follows:

  protected[this] def writeReplace(): AnyRef = new DefaultSerializationProxy(iterableFactory.iterableFactory, this)

In other words, the serialization of all things Iterable are passed into DefaultSerializationProxy, including all subtypes that exist in the wild. Perhaps it should fail at the point of serialization when it detects a type that it cannot handle. Letting it serialize the data, but not deserialize sounds like a potentially data-losing behavior. Another thing to consider is forcing subclasses of Iterable to implement a serialization method. /cc @szeiger

[ashawley]

These are great write-ups! Sounds like the first issue can be carried forward in SI-9237.

For the second issue, should a new bug ticket be created so it can be tracked?

[eed3si9n]

@ashawley Thanks. Yea. The added context is that Scala 2.13 adopts Serialization Proxy pattern, so it became all collection problem, not just List?

I opened scala/bug#11192 for the second issue.