|| at Jun 14, 2012 at 4:28 pm
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.
On Thu, Jun 14, 2012 at 12:07 PM, Mike Kienenberger 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 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.
On Thu, Jun 14, 2012 at 11:04 AM, Mike Kienenberger 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 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
On Thu, Jun 14, 2012 at 10:53 AM, Mike Kienenberger 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
On Thu, Jun 14, 2012 at 10:36 AM, Michael Gentry wrote:
The subclasses would still only be generated once. I have no desire
to change that aspect.
On Thu, Jun 14, 2012 at 10:14 AM, Mike Kienenberger 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 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.