openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael Dick" <>
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

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


On Mon, May 19, 2008 at 7:05 PM, Patrick Linskey <> 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

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