openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael Dick" <michael.d.d...@gmail.com>
Subject Re: SerialVersionUIDs
Date Mon, 19 May 2008 18:21:00 GMT
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
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message