cayenne-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Kienenberger <mkien...@gmail.com>
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
http://docs.oracle.com/javase/7/docs/platform/serialization/spec/version.html,
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 <mgentry@masslight.net> 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 <mkienenb@gmail.com> 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 <mgentry@masslight.net> 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 <mkienenb@gmail.com>
wrote:
>>>> 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 <mgentry@masslight.net>
wrote:
>>>>> 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 <mkienenb@gmail.com>
wrote:
>>>>>> 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 <mgentry@masslight.net>
wrote:
>>>>>>> The subclasses would still only be generated once.  I have no
desire
>>>>>>> to change that aspect.
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> mrg
>>>>>>>
>>>>>>>
>>>>>>> On Thu, Jun 14, 2012 at 10:14 AM, Mike Kienenberger <mkienenb@gmail.com>
wrote:
>>>>>>>> +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 <mgentry@masslight.net>
wrote:
>>>>>>>>> Going back to https://issues.apache.org/jira/browse/CAY-1622
...
>>>>>>>>>
>>>>>>>>> How about if Cayenne Modeler has an option for the following
choices:
>>>>>>>>>
>>>>>>>>> A) Generate @SuppressWarnings("serial") in the super/sub
classes.
>>>>>>>>>
>>>>>>>>> B) Generate a a calculated serialVersionUID in the superclass
and
>>>>>>>>> default the value in the subclass:
>>>>>>>>>
>>>>>>>>> _Foo: protected static final long serialVersionUID =
[calculated];
>>>>>>>>> Foo: protected static final long serialVersionUID = _Foo.serialVersionUID;
>>>>>>>>>
>>>>>>>>> This way the superclass will get a new value should the
attributes
>>>>>>>>> change and the default value for the subclass will be
the same as the
>>>>>>>>> superclass, but the developer can override this if they
wish.
>>>>>>>>>
>>>>>>>>> Thoughts?
>>>>>>>>>
>>>>>>>>> mrg

Mime
View raw message