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 y
and the compiler generates say -2 for the ID , you will encounter
problems when you try and grab the persisted version as the IDs no
longer match.
Rick Hillegas wrote:
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 the class behavior may change between
versions, the non-transient fields won't.
But I'm still not grasping the serialization issue we're addressing
here. How do we get into a situation where there are two different
versions of one of these classes? Is anyone persisting these classes
across upgrades of the Derby code?
Perhaps all that's being addressed here is the following
recommendation from the javadoc of java.io.Serializable: "However, it
is /strongly recommended/ that all serializable classes explicitly
declare serialVersionUID values, since the default serialVersionUID
computation is highly sensitive to class details that may vary
depending on compiler implementations..." I don't think we have this
problem, though: at release time we produce a standard, vetted version
of Derby for which the compiler is constant.
Thanks for helping me puzzle through this.
Regards,
-Rick
David W. Van Couvering wrote:
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 this, then you will get an exception saying the
class is not compatible if the VM determines that version UID
(basically a hash) is different. There is documentation explaining
how this UID is determined, and I struggled to get it right, but
finally I had to set the serialVersionUID.
Note that you have to set the serial version UID on the *second* and
subsequent versions of the class, it's not required for the first
version of the class. Basically, you run serialver on the first
version of the class, and then use this to set serialVersionUID in
the second version.
I wrote some tests to verify serialization compatibility between
versions of classes but never got to the point of checking them in.
They may be valuable, and could be added to our compatibility tests,
so if you'd like I can poke around and find them.
One bug I uncovered in my tests was that for one of the data sources
the serialversion UID was not public, so I was getting failures. Now
I can't remember if I checked in that fix or not.
David
Rick Hillegas wrote:
I'm confused about the presence of serialVersionUIDs in the
DataSources exposed by our network client (e.g.,
ClientConnectionPoolDataSource). I think I understand why these
classes are serializable (JNDI wants to serialize them). But I don't
understand why we are forcibly setting the serialization id. I don't
see any documentation explaining the serialization problem this
addresses, stating the implications for engineers editting these
classes, or describing our expectations at version upgrade.
Can someone shed some light on this?
Thanks,
-Rick
