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:46:42 GMT
It seems to me that subclass versioning would be designed to be
independent of the superclass versioning.   Otherwise, if you upgraded
a library containing a superclass, it would require breaking the
principle of encapsulation, since you would need to know how the
internals of every object above you handled serialization.

Doesn't make it true, but it does make it probable.


On Thu, Jun 14, 2012 at 12:37 PM, Mike Kienenberger <mkienenb@gmail.com> wrote:
> 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