openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Patrick Linskey <plins...@gmail.com>
Subject Re: SerialVersionUIDs
Date Mon, 19 May 2008 18:23:47 GMT
> There might be better ways to test it that I haven't tried - I'm  
> open to
> suggestions.

I've had success with the opposite approach -- manually serialize  
something from the old version, store that in revision control, and  
then assert that the newer code can successfully deserialize the data.

Of course, this only provides certain serialization guarantees, but  
it's better than nothing.

-Patrick

On May 19, 2008, at 11:21 AM, Michael Dick wrote:

> Hi Patrick,
>
> I agree completely about the testcase, but I don't have one ready at  
> the
> moment.
>
> What I've done in the past is keep an old version of the class around
> serialize with the old version - deserialize with the new version.  
> We could
> do the same sort of thing in a testcase - downloading the previous  
> release
> and using that to serialize etc. The test would require internet  
> access (or
> at least a copy in your maven repos) - which is less than ideal.
>
> There might be better ways to test it that I haven't tried - I'm  
> open to
> suggestions.
>
> -Mike
>
> On Mon, May 19, 2008 at 7:05 PM, Patrick Linskey  
> <plinskey@gmail.com> wrote:
>
>> Let's fix it and rebuild a release. Interop is a good thing.
>>
>> Do we have any tests that demonstrate and enforce serialization
>> compatibility across versions? It seems like if we are interested  
>> in making
>> interop guarantees, then we should come up with some test cases  
>> that we can
>> rely on moving forward.
>>
>> -Patrick
>>
>>
>> On May 19, 2008, at 9:19 AM, Michael Dick wrote:
>>
>> Earlier today I changed the serialVersionUIDs for  
>> DetachedStateManager in
>>> trunk and the 1.0.x branch.
>>>
>>> At the time I thought that those were the only branches where we  
>>> specified
>>> the UID, but it looks like it's present in the 1.1.x branch as  
>>> well. the
>>> 1.1.x branch can certainly be updated as well, but with 1.1.0  
>>> nearly out
>>> the
>>> door it's a little late to make the change.
>>>
>>> The original problem was that we encountered an inconsistent
>>> serialVersionUID, depending on the JVM (OPENJPA-559). In that JIRA a
>>> serialUID was added, but it was based on version from trunk, not the
>>> version
>>> found in 1.0.x.
>>>
>>> As a result we were compatible between JVMs but not between  
>>> releases ie if
>>> you serialized a DetachedStateManager on version 1.0.2 or 1.0.1 it  
>>> could
>>> not
>>> be deserialized on 1.2.x. Switching the value to the one that was
>>> generated
>>> on 1.0.2 allows the deserialization to work. We've changed a  
>>> method name
>>> (throwing off the generated serial uid) but it doesn't appear to  
>>> be an
>>> incompatible change (ie no fields were removed etc).
>>>
>>> Since the original change was made to the 1.1.x branch we either  
>>> need to
>>> hold up 1.1.0 and update its copy or  undo this morning's changes  
>>> and deal
>>> with a break in compatibility between 1.0.2 and 1.0.3 and onward.
>>>
>>> Does anyone have a strong preference?
>>>
>>>
>>> -mike
>>>
>>
>> --
>> Patrick Linskey
>> 202 669 5907
>>
>>

-- 
Patrick Linskey
202 669 5907


Mime
View raw message