Grokbase Groups Cayenne dev June 2012
FAQ
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

Search Discussions

  • Mike Kienenberger at Jun 14, 2012 at 2:15 pm
    +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.

    Thoughts?

    mrg
  • Michael Gentry at Jun 14, 2012 at 2:37 pm
    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 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.

    Thoughts?

    mrg
  • Mike Kienenberger at Jun 14, 2012 at 2:53 pm
    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 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 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.

    Thoughts?

    mrg
  • Michael Gentry at Jun 14, 2012 at 2:58 pm
    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 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 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 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.

    Thoughts?

    mrg
  • Mike Kienenberger at Jun 14, 2012 at 3:05 pm
    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
    can tell.

    Thanks,

    mrg

    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
    know"
    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.

    Thanks,

    mrg

    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.

    Thoughts?

    mrg
  • Michael Gentry at Jun 14, 2012 at 4:02 pm
    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 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
    can tell.

    Thanks,

    mrg

    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
    know"
    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.

    Thanks,

    mrg

    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.

    Thoughts?

    mrg
  • Mike Kienenberger at Jun 14, 2012 at 4:07 pm
    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.

    mrg

    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
    can tell.

    Thanks,

    mrg

    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
    know"
    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.

    Thanks,

    mrg

    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.

    Thoughts?

    mrg
  • Michael Gentry 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.

    mrg
    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.

    mrg

    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
    can tell.

    Thanks,

    mrg

    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
    know"
    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.

    Thanks,

    mrg

    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.

    Thoughts?

    mrg
  • Mike Kienenberger at Jun 14, 2012 at 4:47 pm
    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 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 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.

    mrg

    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
    can tell.

    Thanks,

    mrg

    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
    know"
    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.

    Thanks,

    mrg

    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.

    Thoughts?

    mrg
  • Mike Kienenberger at Jun 14, 2012 at 4:47 pm
    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 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 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 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.

    mrg

    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
    can tell.

    Thanks,

    mrg

    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
    know"
    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.

    Thanks,

    mrg

    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.

    Thoughts?

    mrg
  • Andrus Adamchik at Jun 15, 2012 at 8:40 am

    On Jun 14, 2012, at 7:46 PM, Mike Kienenberger wrote:

    It seems to me that subclass versioning would be designed to be
    independent of the superclass versioning.
    I haven't researched that deeply, but IIRC this is correct. There's no inheritance of serialVersionUID.


    Also re:superclass... If it is a CayenneDataObject subclass, it does not include any ivars either. It is all read-through to CayenneDataObject. So all of the _Foo should have the same serialVersionUID.

    ROP client superclasses on the other hand are field-based...

    Andrus
  • Andrus Adamchik at Jun 15, 2012 at 8:43 am
    The docs seem to imply that too:

    http://docs.oracle.com/javase/1.5.0/docs/api/java/io/Serializable.html

    "It is also strongly advised that explicit serialVersionUID declarations use the private modifier where possible, since such declarations apply only to the immediately declaring class--serialVersionUID fields are not useful as inherited members."

    On Jun 15, 2012, at 11:39 AM, Andrus Adamchik wrote:
    On Jun 14, 2012, at 7:46 PM, Mike Kienenberger wrote:

    It seems to me that subclass versioning would be designed to be
    independent of the superclass versioning.
    I haven't researched that deeply, but IIRC this is correct. There's no inheritance of serialVersionUID.


    Also re:superclass... If it is a CayenneDataObject subclass, it does not include any ivars either. It is all read-through to CayenneDataObject. So all of the _Foo should have the same serialVersionUID.

    ROP client superclasses on the other hand are field-based...

    Andrus
  • Durchholz, Joachim at Jun 15, 2012 at 8:58 am
    I'm reading that the deserialization mechanism takes the serialVersionUID of all superclasses into account.
    So yes the serialVersionUID needs to be set on each class, and subclasses can retain their serialVersionUID even if the superclass' serialVersionUID changes.
    Also, if a class does not have any serializable fields, it can simply have a fixed serialVersionUID that never changes, say, 1L (that's the common way to say "this class does not have anything serializable", or "this class will never change", or "I'm taking responsibility for manually bumping up the servialVersionUID whenever a serialization-relevant change happens").

    That's what I gather from reading various sources in the web.
    I'm not seeing any official mention of the issue, unfortunately.
    I guess this means reading the source, and/or testing with as many JDKs as humanly possible.
  • Michael Gentry at Jun 15, 2012 at 1:10 pm
    I'm perfectly OK for using 1L in the subclasses if it makes sense to
    everyone else.

    On Fri, Jun 15, 2012 at 4:57 AM, Durchholz, Joachim
    wrote:
    Also, if a class does not have any serializable fields, it can simply have a fixed serialVersionUID that never changes, say, 1L (that's the common way to say "this class does not have anything serializable", or "this class will never change", or "I'm taking responsibility for manually bumping up the servialVersionUID whenever a serialization-relevant change happens").
  • Michael Gentry at Jun 15, 2012 at 12:58 pm
    In my mind, you would simply treat the properties as ivars in whatever
    method you use to compute the serialVersionUID. If you
    add/remove/rename a property, the signature changes.

    mrg

    On Fri, Jun 15, 2012 at 4:39 AM, Andrus Adamchik wrote:
    Also re:superclass... If it is a CayenneDataObject subclass, it does not include any ivars either. It is all read-through to CayenneDataObject. So all of the _Foo should have the same  serialVersionUID.
  • Andrus Adamchik at Jun 15, 2012 at 2:22 pm
    Actually no. "serialVersionUID" is specifically intended for Java built-in serialization mechanism, that only cares about ivars and their types, so higher level Cayenne abstractions are of no consequence.

    Andrus
    On Jun 15, 2012, at 3:58 PM, Michael Gentry wrote:

    In my mind, you would simply treat the properties as ivars in whatever
    method you use to compute the serialVersionUID. If you
    add/remove/rename a property, the signature changes.

    mrg

    On Fri, Jun 15, 2012 at 4:39 AM, Andrus Adamchik wrote:
    Also re:superclass... If it is a CayenneDataObject subclass, it does not include any ivars either. It is all read-through to CayenneDataObject. So all of the _Foo should have the same serialVersionUID.
  • Durchholz, Joachim at Jun 15, 2012 at 8:35 am
    Don't take this as an expert opinion, but since subclasses contain all
    member fields of the superclass, I'd expect that a subclass needs to
    have a changed SerialVersionUUID if the superclass changes.

    Testing this aspect might be in order.

    -----Original Message-----
    From: Mike Kienenberger
    Sent: Thursday, June 14, 2012 6:07 PM
    To: dev@cayenne.apache.org
    Subject: Re: Serialization warnings

    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.
  • Aristedes Maniatis at Jun 15, 2012 at 9:15 am

    On 15/06/12 6:34pm, Durchholz, Joachim wrote:
    Don't take this as an expert opinion, but since subclasses contain all
    member fields of the superclass, I'd expect that a subclass needs to
    have a changed SerialVersionUUID if the superclass changes.

    Testing this aspect might be in order.
    My question would be: test what? In the real world are SerialVersionUUID particularly useful for Cayenne entities? With Cayenne ROP, I've never seen any code in Hessian which pays any attention to the version. Is this more useful with a cluster of application servers and different instances running different versions of the code? Are there are specific use cases where Cayenne entities would be involved?


    Ari




    --
    -------------------------->
    Aristedes Maniatis
    GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
  • Andrus Adamchik at Jun 15, 2012 at 9:21 am
    Serialized HttpSessions is one common case. This is on in Tomcat by default, so every time you restart the server, Tomcat goes through serialization cycle.

    Andrus
    On Jun 15, 2012, at 12:14 PM, Aristedes Maniatis wrote:
    On 15/06/12 6:34pm, Durchholz, Joachim wrote:
    Don't take this as an expert opinion, but since subclasses contain all
    member fields of the superclass, I'd expect that a subclass needs to
    have a changed SerialVersionUUID if the superclass changes.

    Testing this aspect might be in order.
    My question would be: test what? In the real world are SerialVersionUUID particularly useful for Cayenne entities? With Cayenne ROP, I've never seen any code in Hessian which pays any attention to the version. Is this more useful with a cluster of application servers and different instances running different versions of the code? Are there are specific use cases where Cayenne entities would be involved?


    Ari




    --
    -------------------------->
    Aristedes Maniatis
    GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A

  • Aristedes Maniatis at Jun 15, 2012 at 9:31 am
    Yes, but this really only has an effect if you serialise the Cayenne entities across a cluster, or to a database (where they are read by a new version of the application which you launch). In that case do we want to automatically throw a serialisation exception for the user when the the change in the Cayenne model was unimportant to the operation of the application?

    Isn't this something which the developer should change by hand in the subclass and not have Cayenne automatically invalidate every object in the _superclass just because there was some (possibly insignificant) change in the model?

    Or am I missing the use cases of this feature?Are we actually helping?


    Ari

    On 15/06/12 7:21pm, Andrus Adamchik wrote:
    Serialized HttpSessions is one common case. This is on in Tomcat by default, so every time you restart the server, Tomcat goes through serialization cycle.

    Andrus
    On Jun 15, 2012, at 12:14 PM, Aristedes Maniatis wrote:
    On 15/06/12 6:34pm, Durchholz, Joachim wrote:
    Don't take this as an expert opinion, but since subclasses contain all
    member fields of the superclass, I'd expect that a subclass needs to
    have a changed SerialVersionUUID if the superclass changes.

    Testing this aspect might be in order.
    My question would be: test what? In the real world are SerialVersionUUID particularly useful for Cayenne entities? With Cayenne ROP, I've never seen any code in Hessian which pays any attention to the version. Is this more useful with a cluster of application servers and different instances running different versions of the code? Are there are specific use cases where Cayenne entities would be involved?


    Ari




    --
    -------------------------->
    Aristedes Maniatis
    GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A

    --
    -------------------------->
    Aristedes Maniatis
    GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
  • Andrus Adamchik at Jun 15, 2012 at 9:42 am
    See my earlier message. IMO serialVersionUID of the server superclass is immutable as it doesn't declare any properties. For ROP client serialVersionUID will depend on the model changes, but only on those that change java signature of the ivars (e.g. changing DbAttribute LENGTH should not result in serialVersionUID change; renaming ObjAttribute should). And I think this should be handled automatically (why not?)

    The scope of "invalidation" is really just previously serialized objects stored somewhere in a binary form. And I guess those should be invalidated when the ROP object format changes, right?

    Andrus

    On Jun 15, 2012, at 12:30 PM, Aristedes Maniatis wrote:

    Yes, but this really only has an effect if you serialise the Cayenne entities across a cluster, or to a database (where they are read by a new version of the application which you launch). In that case do we want to automatically throw a serialisation exception for the user when the the change in the Cayenne model was unimportant to the operation of the application?

    Isn't this something which the developer should change by hand in the subclass and not have Cayenne automatically invalidate every object in the _superclass just because there was some (possibly insignificant) change in the model?

    Or am I missing the use cases of this feature?Are we actually helping?


    Ari

    On 15/06/12 7:21pm, Andrus Adamchik wrote:
    Serialized HttpSessions is one common case. This is on in Tomcat by default, so every time you restart the server, Tomcat goes through serialization cycle.

    Andrus
    On Jun 15, 2012, at 12:14 PM, Aristedes Maniatis wrote:
    On 15/06/12 6:34pm, Durchholz, Joachim wrote:
    Don't take this as an expert opinion, but since subclasses contain all
    member fields of the superclass, I'd expect that a subclass needs to
    have a changed SerialVersionUUID if the superclass changes.

    Testing this aspect might be in order.
    My question would be: test what? In the real world are SerialVersionUUID particularly useful for Cayenne entities? With Cayenne ROP, I've never seen any code in Hessian which pays any attention to the version. Is this more useful with a cluster of application servers and different instances running different versions of the code? Are there are specific use cases where Cayenne entities would be involved?


    Ari




    --
    -------------------------->
    Aristedes Maniatis
    GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A

    --
    -------------------------->
    Aristedes Maniatis
    GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A

  • Michael Gentry at Jun 15, 2012 at 1:12 pm
    I didn't think this worked, anyway? If Tomcat (and others) serialize
    a bunch of Cayenne objects, then deserialize on startup, aren't they
    detached from their DataContext now?
    On Fri, Jun 15, 2012 at 5:21 AM, Andrus Adamchik wrote:
    Serialized HttpSessions is one common case. This is on in Tomcat by default, so every time you restart the server, Tomcat goes through serialization cycle.
  • Mike Kienenberger at Jun 15, 2012 at 2:11 pm
    I think we should set the serialization of the generated superclass to 1L
    because it doesn't have any serializable fields, and likely never will.

    I also think we should set the generate-once subclasses to 1L because it
    won't have any serializable fields unless the developer does something
    further.

    Both values should be marked private.

    I have in the past written a web app that serialized Cayenne Data Objects
    in a request and then restored them in future requests. Yes, the objects
    are detached from the DataContext when that happens (at least as of Cayenne
    2). I had to augment the serialization methods to reattach the objects
    back to a context, if I recall.
    On Fri, Jun 15, 2012 at 9:11 AM, Michael Gentry wrote:

    I didn't think this worked, anyway? If Tomcat (and others) serialize
    a bunch of Cayenne objects, then deserialize on startup, aren't they
    detached from their DataContext now?
    On Fri, Jun 15, 2012 at 5:21 AM, Andrus Adamchik wrote:
    Serialized HttpSessions is one common case. This is on in Tomcat by
    default, so every time you restart the server, Tomcat goes through
    serialization cycle.
  • Durchholz, Joachim at Jun 15, 2012 at 12:37 pm

    On 15/06/12 6:34pm, Durchholz, Joachim wrote:
    Don't take this as an expert opinion, but since subclasses contain all
    member fields of the superclass, I'd expect that a subclass needs to
    have a changed SerialVersionUUID if the superclass changes.

    Testing this aspect might be in order.
    My question would be: test what?
    Test whether changing the superclass in a serialization-breaking way, without updating the subclass' serialVersionUID, causes a deserialization failure.
    In the real world are SerialVersionUUID particularly useful for Cayenne
    entities? With Cayenne ROP, I've never seen any code in Hessian which
    pays any attention to the version.
    Java's @Serializable mechanism reports mismatches via exceptions.
    So the absence of any special code means that everything is as it should be.

    Assuming those @Serializable annotations are there to make Hessian work, that is.
    If Hessian does not use Java's standard serialization, I don't see the point of those @Serializable and serialVersionUID declarations in the first place.
    Is this more useful with a cluster of application servers and different
    instances running different versions of the code? Are there are specific
    use cases where Cayenne entities would be involved?
    Yes, if client and server disagree about the format of the serialized data.
    This could happen if the entity classes were updated on one side but not on the other (due to some roll-out mishap, for example).
    Sounds like fail-fast is a good idea in such a scenario.
  • Aristedes Maniatis at Jun 15, 2012 at 1:15 pm

    On 15/06/12 10:36pm, Durchholz, Joachim wrote:

    Assuming those @Serializable annotations are there to make Hessian work, that is.
    If Hessian does not use Java's standard serialization, I don't see the point of those @Serializable and serialVersionUID declarations in the first place.

    I don't pretend to understand it all, but here's how Hessian does its work:

    https://github.com/ebourg/hessian/blob/git-svn/src/com/caucho/hessian/io/StringValueDeserializer.java

    That is using java.lang.reflect.Constructor, so is that is aware of serialVersionUID? However, my understanding is that Hessian is much more forgiving than Java serialisation.

    http://maillist.caucho.com/pipermail/hessian-interest/2010-November/000964.html


    Scott is one of the lead Hessian developers.


    Ari


    --
    -------------------------->
    Aristedes Maniatis
    GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
  • Andrus Adamchik at Jul 18, 2013 at 1:50 pm
    FYI - this is fixed in 3.2 for CayenneDataObject descendants (i.e. all but ROP classes) :

    https://issues.apache.org/jira/browse/CAY-1851
    On Jun 14, 2012, at 5:06 PM, 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.

    Thoughts?

    mrg

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupdev @
categoriescayenne
postedJun 14, '12 at 2:07p
activeJul 18, '13 at 1:50p
posts27
users5
websitecayenne.apache.org

People

Translate

site design / logo © 2022 Grokbase