Reason to serialVersionUID your serializable classes
Quoting Eclipse FAQ: “When classes compiled in Eclipse are written to an object stream, you may not be able to read them back in a program that was compiled elsewhere. Many people blame this on the Eclipse compiler, assuming that it is somehow not conforming properly to spec. In fact, this can be a problem between any two compilers or even two versions of a compiler provided by the same vendor. If you need object serialization, the only way to be safe is to explicitly define the serialVersionUID in your code! /…/ Bottom line: Always define the serialVersionUID explicitly in your source files.”
My question is: can there be an audit to automatically detect source files where you explicitly defined serialVersionUID that is out of date? A nice-to-have addition would be a quick-fix for repairing serialVersionUID. Current eclipse quick-fix supports only generating serialVersionUID from scratch.
4 Comments »
RSS feed for comments on this post.
| TrackBack URI
You can also bookmark
this on del.icio.us or check the cosmos
Good to know.
However, I was thinking about this question: “can there be an audit to automatically detect source files where you explicitly defined serialVersionUID that is out of date?”. I’m not sure if this would be useful, because I think it is the only point of serialVersionUID that it can get “out of date” with class, and yet the number would stay the same, thus allowing serialization anyway.
For one example, what if you create a serialVersionUID with another compiler, and then you open up the code in Eclipse and Eclipse finds that the serialVersionUID is wrong; if you “fix” it to the linking of Eclipse’s compiler, you break serialization compatibility (unless you always tend to run binaries that have been compiled with Eclipse).
That said, I can imagine other cases where it could be useful to check if serialVersionUID is out of date — for example, if you really want to know whether you have changed the signature since you create that number.
Comment by risto — August 24, 2006 @ Thursday, August 24, 5:48 pm
Yes, you are totally right.
So my idea would become to detect if a change in class structure would break serialization that was specified by the generated serialVersionUID.
For example changing a field to static would break serialized object but adding a new field does no harm.
For the reference “Type Changes Affecting Serialization”:
http://java.sun.com/j2se/1.5.0/docs/guide/serialization/spec/version.html#6678
Not sure how this could be done or how useful this might be :)
Comment by ahti.kitsik — August 25, 2006 @ Friday, August 25, 11:50 am
Here is an idea for detecting this through an unit test. I haven’t worked out the details of calling serialver from within the unit test, though.
private void assertSuidUpToDate(Class clazz) {
long actualSUID;
try {
Field field = clazz.getDeclaredField("serialVersionUID");
field.setAccessible(true);
actualSUID = (Long) field.get(null);
} catch (NoSuchFieldException e) {
throw new AssertionError(clazz.getName() + " does not have a serialVersionUID field");
} catch (IllegalAccessException e) {
throw new AssertionError("Got an IllegalAccessException trying to read the serialVersionUID field from class " + clazz.getName());
}
// TODO Call serialver command line utility
long generatedSUID = 0;
Assert.assertEquals(generatedSUID, actualSUID);
}
Comment by David Wright — December 3, 2008 @ Wednesday, December 3, 5:16 pm
hmm, this is an idea.. thanks, David!
Comment by Ahti — December 3, 2008 @ Wednesday, December 3, 8:39 pm