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 <[email protected]> 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 <[email protected]> > 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 <[email protected]> >> 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 <[email protected]> >>> 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 <[email protected]> >>>> 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 <[email protected]> >>>>> 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 <[email protected]> >>>>>> 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 >>>>>>> <[email protected]> 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 >>>>>>>> <[email protected]> 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
