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 22:56:39 GMT
Thanks, Lance. This is a very sensible suggestion.


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 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