db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David W. Van Couvering" <David.Vancouver...@Sun.COM>
Subject Re: serialization of Derby DataSources
Date Fri, 21 Apr 2006 18:16:25 GMT
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 

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.


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

View raw message