cayenne-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Kienenberger <>
Subject Re: Serialization warnings
Date Thu, 14 Jun 2012 16:37:06 GMT
This is where my knowledge of serialization falls flat on its face,
but I suspect that you should not change the serialVersionUID just
because a superclass has changed its serialVersionUID.   I tried to
look at "Versioning of Serializable Objects " at,
but I wasn't able to come to a conclusion as the spec could be read
either way.   Hopefully someone who has used serialization recently
will chime in.

On Thu, Jun 14, 2012 at 12:27 PM, Michael Gentry <> wrote:
> As long as the subclass is still an empty shell, I think it actually
> makes sense for the serialVersionUID to change when the superclass
> version changes.  Using serialVersionUID = 1L in the subclass would
> mean attribute changes in the superclass are still considered
> identical unless the developer remembered to go change the subclass
> (less likely to be remembered).  If they start to add stuff to the
> subclass, I hope they'd notice the default serialVersionUID value and
> change it, but that is their decision, of course.  Personally, I'd
> just suppress the warning and go on with my life, but we should at
> least have an option, I think.
> mrg
> On Thu, Jun 14, 2012 at 12:07 PM, Mike Kienenberger <> wrote:
>> But should the subclass serialVersionUID change just because the
>> superclass changed?   That's what you are proposing.   I suspect not,
>> but again, I'm not an expert in the field.
>> serialVersionUID = 1L; might be a better choice and might also
>> encourage the developer to update it when he adds things.
>> On Thu, Jun 14, 2012 at 12:02 PM, Michael Gentry <> wrote:
>>> Well, by default, there are no instance variables or methods in the
>>> subclass because it is a shell over the superclass.  If the developer
>>> starts adding things, they can choose how to calculate the
>>> serialVersionUID, too?  At least that's my current thinking.
>>> mrg
>>> On Thu, Jun 14, 2012 at 11:04 AM, Mike Kienenberger <>
>>>> Let's assume that we do want to specify the serialVersionUID for the
>>>> generate-once classes rather than making the developer do it.   Is it
>>>> appropriate to link it to the superclass?   It's been a long while
>>>> since I worked with serialVersionUIDs, but my recollection is that
>>>> each class's serialVersionUID should be independent of changes in
>>>> superclasses and only dependent on instance variables in itself.   But
>>>> I could be wrong.
>>>> On Thu, Jun 14, 2012 at 10:58 AM, Michael Gentry <>
>>>>> Ah.  Well, if you leave serialVersionUID out of either class, you get
>>>>> a warning in that class.  Same applies to the
>>>>> @SuppressWarnings("serial") annotation.  From the perspective of
>>>>> reducing warning messages, it needs to be in both classes from what I
>>>>> can tell.
>>>>> Thanks,
>>>>> mrg
>>>>> On Thu, Jun 14, 2012 at 10:53 AM, Mike Kienenberger <>
>>>>>> Right.  I understand that.  I just don't remember if it's appropriate
>>>>>> to specify a serialVersionUID for the subclasses.   "Undecided"
>>>>>> probably was the wrong word in my original message -- more like "don't
>>>>>> know"
>>>>>> On Thu, Jun 14, 2012 at 10:36 AM, Michael Gentry <>
>>>>>>> The subclasses would still only be generated once.  I have no
>>>>>>> to change that aspect.
>>>>>>> Thanks,
>>>>>>> mrg
>>>>>>> On Thu, Jun 14, 2012 at 10:14 AM, Mike Kienenberger <>
>>>>>>>> +1 for doing this for the generate-always classes.
>>>>>>>> Undecided about the generate-once subclasses.
>>>>>>>> On Thu, Jun 14, 2012 at 10:06 AM, Michael Gentry <>
>>>>>>>>> Going back to
>>>>>>>>> How about if Cayenne Modeler has an option for the following
>>>>>>>>> A) Generate @SuppressWarnings("serial") in the super/sub
>>>>>>>>> B) Generate a a calculated serialVersionUID in the superclass
>>>>>>>>> default the value in the subclass:
>>>>>>>>> _Foo: protected static final long serialVersionUID =
>>>>>>>>> Foo: protected static final long serialVersionUID = _Foo.serialVersionUID;
>>>>>>>>> This way the superclass will get a new value should the
>>>>>>>>> change and the default value for the subclass will be
the same as the
>>>>>>>>> superclass, but the developer can override this if they
>>>>>>>>> Thoughts?
>>>>>>>>> mrg

View raw message