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());
}

Assert.assertEquals(generatedSUID, actualSUID);
}


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

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.