Imported From: https://issues.scala-lang.org/browse/SI-6713?orig=1
Reporter: John Crowley (jcrowley)
Affected Versions: 2.9.3-RC1
Attachments:

• SerialUIDTest.scala (created on Nov 27, 2012 6:25:37 PM UTC, 22577 bytes)

@paulp said:
Do you have some insight into why the exception identifies scala.reflect.ClassTypeManifest? Since there is no manifest in any of the code you included.

John Crowley (jcrowley) said:
Paul,

Not a clue -- it was a puzzle to me also. On the working (Windows) environment, when I forced an error by diddling with the local SerialVersionUID the error message did include the correct class name.

I'm trying to see if I can reproduce the problem in a self-contained app. Will post that if I am successful.

John

John Crowley (jcrowley) said:
Standalone app worked correctly. Researching the original code further -- it might be my problem.

On the server the instance is serialized into a byte stream, then converted to Base64 for transmission, and converted back at the client. I need to verify that nothing changes during the conversion/reconversion.

@paulp said:
It might be unrelated, but looking into this I discovered: scala/scala#1673

John Crowley (jcrowley) said:
Good detective work -- amazing how bugs can hide for years! I suspect that my problem still exists since each case uses the 13L form, which seemed to be the only one that worked in your test code. Will continue to verify correct encoding and transmission of the raw byte stream and report back.

John Crowley (jcrowley) said:
Paul,

I did not solve the original problem, but suspect that it involved an Enumeration (a couple of values were present in the object being serialized). One enumeration had been expanded a bit (a new class extended the basic Value).

I went back and added @SerializeVersionUID to all of these (even the class that extended Value), but still got the same failure. At that point, had to move on ....

As a workaround, I finally changed the objects involved so that they contained nothing but primitive values, Strings, or Arrays of same.

Where there was previously an Enumeration Value it was changed to be the ID of the entry (a simple Int). Added a def to convert that back to the original Value -- so only the Int ID is actually serialized, but the caller can still work with the Enumeration value as before. A kludge to be sure, but have already fiddled with it for 2 days without any real progress.

Also suspect that the "default" calculation of a UID works differently between the environments. Don't know if it's the 64-bit vs 32-bit difference, different Scala versions, or what. (Remember that if it was compiled under 2.9.1 on 32-bit Windows, and built an executable Jar, then it would execute correctly on the OSX machine with Java 1.7.0_09)

Understand that the "default" UID calculation will be very sensitive to any changes to the Class definition, but in this case (at least at the source level) the definitions were identical and it looks like it still calculated different values. That is probably not a good thing. There may also be something nasty going on in how an Enumeration handles serialization.

I'll see if I can build a standalone test case with an Enumeration involved to see if we can further isolate the problem.

John

John Crowley (jcrowley) said:
Cannot corral this at all. Do not know if it is a bug or in my own code or some weird transient in the environment. Closing for now.

Wrote a standalone routine to serialize an object with a couple of Enumerations. It dumps the serialized byte array to the console (with the description of the environment). Also contains a List(String, Array[Byte]) (description, serialization) of test cases that are de-serialized. Ran on 3 different environments, and everything appears to work correctly.

Standalone routine is attached if it would be of any use to anyone. Still scratching my head .....

John