I had to look into this when I was playing around with a classloader for
code sharing.
Basically, by setting the serialVersionUID, you are telling the VM that
you guarantee that the newer version of the class is compatible with the
old version (in terms of serialization).
If you don't set
Thanks, David. I'm afraid I'm still muddled. I think I understand the
basic purpose of serialVersionUID: It's a compiler-generated checksum of
the source which serialization uses as a sanity check. By explicitly
setting this field, the engineer promises to keep the following
contract: Although
Hi Rick,
once the serialVerisonUID is there, you should not remove it as chaos
can break out if the IDs start to differ. IMHO would leave them alone.
One example is you have say someone using say derby version x with a an
ID of 1 and then persisted the object... now u remove the ID in derby
David W. Van Couvering wrote:
My understanding was that they may persist across upgrades because the
data source objects are serialized into a JNDI store. In general we
can *add* non-transient fields but we can't remove or change them.
Thanks for that warning about the JNDI store. It would
Rick Hillegas wrote:
David W. Van Couvering wrote:
My understanding was that they may persist across upgrades because
the data source objects are serialized into a JNDI store. In general
we can *add* non-transient fields but we can't remove or change them.
Thanks for that warning about
Thanks, Lance. This is a very sensible suggestion.
Regards,
-Rick
Lance J. Andersen wrote:
People do strange things. We in the Java SE land have tests which
save serialized object and then test that they can be deserialized
with the next revision. I would suggest adding some tests to the
Right, can't you override the readObject method or whatever it's called?
(Sorry, too lazy to look up the javadoc)
I have some tests, Rick. If you'd like I can send them to you.
Alternately log a JIRA and I can attach the source to the JIRA.
Can't actually spend the time to fully implement
