-
Notifications
You must be signed in to change notification settings - Fork 21
Serialization of case object in 2.9.2 provides different serialVersionUID from 2.9.1 resulting in binary incompatibility #5697
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Imported From: https://issues.scala-lang.org/browse/SI-5697?orig=1
|
@paulp said: 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. |
@oxbowlakes said: Considering the prevalence of case objects and the fact they are by default If I'd had to mark it as |
@paulp said: |
@oxbowlakes said: I've even changed my mind and agree with the decision - sorry for the time wastage. |
@heathermiller said: |
Michael Schmitz (schmmd) said: |
@paulp said: |
@adriaanm said: |
@adriaanm said: |
@adriaanm said: |
a simple definition of a case object:
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:
I would contend that this should be marked as a binary incompatibility.
The text was updated successfully, but these errors were encountered: