Serialization of case object in 2.9.2 provides different serialVersionUID from 2.9.1 resulting in binary incompatibility

[scabug]

a simple definition of a case object:

case object Bippy

is serialized with a different serialVersionUID between 2.9.1 and 2.9.2. This causes issues in (for example) communication between remote actors running under different versions of scala. In the attached file TestSer.scala, first run "Ser" under 2.9.1 and then "Deser" under 2.9.2 and observe the following exception:

Exception in thread "main" java.io.InvalidClassException: test.Bippy$; local class incompatible: stream classdesc serialVersionUID = 4073568934824676524, local class serialVersionUID = 8501393720257665998
  at java.io.ObjectStreamClass.initNonProxy(ObjectStreamClass.java:562)
  at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1582)
  at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1495)
  at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1731)
  at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1328)	
  at java.io.ObjectInputStream.readObject(ObjectInputStream.java:350)

I would contend that this should be marked as a binary incompatibility.

[scabug]

Imported From: https://issues.scala-lang.org/browse/SI-5697?orig=1
Reporter: @oxbowlakes
Affected Versions: 2.9.2
Attachments:

• TestSer.scala (created on Apr 23, 2012 2:01:13 PM UTC, 710 bytes)

[scabug]

@paulp said:
"...the default serialVersionUID computation is highly sensitive to class details that may vary depending on compiler implementations, and can thus result in unexpected serialVersionUID conflicts during deserialization, causing deserialization to fail."

http://docs.oracle.com/javase/6/docs/platform/serialization/spec/class.html

One could argue we should synthesize serialVersionUID in case classes which don't otherwise provide it. But if we don't, and as near as I can tell we don't, then you're on your own. We're not going to treat a quality which is explicitly documented to be "highly sensitive to class details that may vary depending on compiler implementations" as part of the binary compatibility contract.

[scabug]

@oxbowlakes said:
But the quoted text is an observation on the default implementation of serial UID.

Considering the prevalence of case objects and the fact they are by default Serializable, I would expect a sensible implementation, not the default implementation. The sensible implementation for the serial UID of a singleton is a pure function of its "path".

If I'd had to mark it as Serializable myself, I would (of course) agree with you.

[scabug]

@paulp said:
You do agree with me, you just didn't hear me.

[scabug]

@oxbowlakes said:
You are right :-) I was getting muddled between the library providing sensible serial UIDs (for stuff like Option, List etc) and the compiler providing them.

I've even changed my mind and agree with the decision - sorry for the time wastage.

[scabug]

@heathermiller said:
Changing to "Improvement" request, as we can all agree that this isn't a bug, and that it might be nice to have a better solution for issues like these in the future.

[scabug]

Michael Schmitz (schmmd) said:
Shouldn't Option define a serialVersionUID?

[scabug]

@paulp said:
Yes it should, as far as I understand the point of it. (But since the ticket is opened as a "binary incompatibility" bug I wanted to nip that in the bud.)

[scabug]

@adriaanm said:
Un-assigning to foster work stealing, as announced in https://groups.google.com/forum/?fromgroups=#!topic/scala-internals/o8WG4plpNkw

[scabug]

@adriaanm said:
Unassigning and rescheduling to M6 as previous deadline was missed.

[scabug]

@adriaanm said:
binary compatibility does not cover serialization