I have to work with a large number of compiled Java classes which didn't explicitly specify a serialVersionUID. Because their UIDs were arbitrarily generated by the compiler, many of the classes which need to be serialized and deserialized end up causing exceptions, even though the actual class definitions match up. (This is all expected behavior, of course.)
It is impractical for me to go back and fix all of this 3rd-party code.
Therefore, my question is: Is there any way to make the Java runtime ignore differences in serialVersionUIDs, and only fail to deserialize when there are actual differences in structure?
Use CGLIB to insert them into the binary classes?
If you have access to the code base, you could use the SerialVer task for Ant to insert and to modify the
serialVersionUID
in the source code of a serializable class and fix the problem once for all.If you can't, or if this is not an option (e.g. if you have already serialized some objects that you need to deserialize), one solution would be to extend
ObjectInputStream
. Augment its behavior to compare theserialVersionUID
of the stream descriptor with theserialVersionUID
of the class in the local JVM that this descriptor represents and to use the local class descriptor in case of mismatch. Then, just use this custom class for the deserialization. Something like this (credits to this message):How impractical is this to fix ? If you have the source and can rebuild, can you not just run a script over the entire codebase to insert a
everywhere ?
The serialization errors at runtime tell you explicitly what the ID is expected to be. Just change your classes to declare these as the ID and everything will be OK. This does involve you making changes but I don't believe that this can be avoided
You could possibly use Aspectj to 'introduce' the field into each serializable class as it is loaded. I would first introduce a marker interface into each class using the package and then introduce the field using a Hash of the class file for the serialVersionUID
You will need to add the aspectj load time weaver agent to the VM so it can weave the advice into your existing 3rd party classes. Its funny though once you get around to setting Aspectj up, its remarkable the number of uses that you will put to.
HTH
ste