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:07:08 GMT
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