Skip to content
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

Jump to bottom

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

Closed
scabug opened this issue Apr 23, 2012 · 11 comments
Closed

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

scabug opened this issue Apr 23, 2012 · 11 comments
Assignees
@adriaanm
Labels
enhancement serialization won't fix
Milestone
2.11.0-M8

Comments

@scabug
Copy link

scabug commented Apr 23, 2012

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
Copy link
Author

scabug commented Apr 23, 2012

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
Copy link
Author

scabug commented Apr 23, 2012

@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
Copy link
Author

scabug commented Apr 23, 2012

@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
Copy link
Author

scabug commented Apr 23, 2012

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

@scabug
Copy link
Author

scabug commented Apr 23, 2012

@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
Copy link
Author

scabug commented May 8, 2012

@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
Copy link
Author

scabug commented May 10, 2012

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

@scabug
Copy link
Author

scabug commented May 10, 2012

@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
Copy link
Author

scabug commented Mar 15, 2013

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

@scabug
Copy link
Author

scabug commented Jul 10, 2013

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

@scabug
Copy link
Author

scabug commented Dec 11, 2013

@adriaanm said:
binary compatibility does not cover serialization

@scabug scabug closed this as completed Dec 11, 2013
@scabug scabug added this to the 2.11.0-M8 milestone Apr 7, 2017
@scabug scabug mentioned this issue Apr 7, 2017
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@adriaanm adriaanm

Labels
enhancement serialization won't fix
Projects
None yet
Milestone
2.11.0-M8
Development

No branches or pull requests
2 participants
@adriaanm @scabug