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.
RSS
LinkedIn
Facebook
4 Comments
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.
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
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);
}
hmm, this is an idea.. thanks, David!