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
