db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick Hillegas <Richard.Hille...@Sun.COM>
Subject Re: serialization of Derby DataSources
Date Fri, 21 Apr 2006 18:58:43 GMT
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
>


Mime
View raw message