db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lance J. Andersen" <Lance.Ander...@Sun.COM>
Subject Re: serialization of Derby DataSources
Date Fri, 21 Apr 2006 22:48:26 GMT
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 test suite for 
any serializable objects

Rick Hillegas wrote:
> Thanks, Lance. I agree. We seem to have a muddle if someone adds a new 
> non-transient field to one of these classes: either a) the engineer 
> changes the serialVersionUID, giving rise to the problem you mention 
> or b) the serialVersionUID isn't changed and deserialization fails 
> because the new field is missing from the persisted stream. Hopefully 
> we don't mean for these objects to persist across Derby upgrades. Hard 
> to tell from the code.
> Regards,
> -Rick
> Lance J. Andersen wrote:
>> 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

View raw message