You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openjpa.apache.org by Michael Dick <mi...@gmail.com> on 2008/05/19 18:19:59 UTC
SerialVersionUIDs
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
Re: SerialVersionUIDs
Posted by Patrick Linskey <pl...@gmail.com>.
> 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
> <pl...@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
Re: SerialVersionUIDs
Posted by Michael Dick <mi...@gmail.com>.
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 <pl...@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
>
>
Re: SerialVersionUIDs
Posted by Patrick Linskey <pl...@gmail.com>.
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