You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cayenne.apache.org by Michael Gentry <mg...@masslight.net> on 2012/06/14 16:06:55 UTC
Serialization warnings
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
Re: Serialization warnings
Posted by Andrus Adamchik <an...@objectstyle.org>.
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 <mg...@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
>
Re: Serialization warnings
Posted by Mike Kienenberger <mk...@gmail.com>.
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 <mg...@masslight.net>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 <an...@objectstyle.org>
> 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.
>
Re: Serialization warnings
Posted by Michael Gentry <mg...@masslight.net>.
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 <an...@objectstyle.org> 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.
Re: Serialization warnings
Posted by Andrus Adamchik <an...@objectstyle.org>.
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
>
>
>
Re: Serialization warnings
Posted by Aristedes Maniatis <ar...@maniatis.org>.
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
Re: Serialization warnings
Posted by Andrus Adamchik <an...@objectstyle.org>.
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
>
>
>
Re: Serialization warnings
Posted by Aristedes Maniatis <ar...@maniatis.org>.
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
RE: Serialization warnings
Posted by "Durchholz, Joachim" <Jo...@hennig-fahrzeugteile.de>.
> 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.
Re: Serialization warnings
Posted by Aristedes Maniatis <ar...@maniatis.org>.
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
RE: Serialization warnings
Posted by "Durchholz, Joachim" <Jo...@hennig-fahrzeugteile.de>.
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 [mailto:mkienenb@gmail.com]
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.
Re: Serialization warnings
Posted by Michael Gentry <mg...@masslight.net>.
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
<Jo...@hennig-fahrzeugteile.de> 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").
RE: Serialization warnings
Posted by "Durchholz, Joachim" <Jo...@hennig-fahrzeugteile.de>.
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.
Re: Serialization warnings
Posted by Andrus Adamchik <an...@objectstyle.org>.
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 <an...@objectstyle.org> 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.
>
Re: Serialization warnings
Posted by Michael Gentry <mg...@masslight.net>.
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 <an...@objectstyle.org> 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.
Re: Serialization warnings
Posted by Andrus Adamchik <an...@objectstyle.org>.
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
>
>
Re: Serialization warnings
Posted by Andrus Adamchik <an...@objectstyle.org>.
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
Re: Serialization warnings
Posted by Mike Kienenberger <mk...@gmail.com>.
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 <mk...@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 <mg...@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 <mk...@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 <mg...@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 <mk...@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 <mg...@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 <mk...@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 <mg...@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 <mk...@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 <mg...@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
Re: Serialization warnings
Posted by Mike Kienenberger <mk...@gmail.com>.
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 <mg...@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 <mk...@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 <mg...@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 <mk...@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 <mg...@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 <mk...@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 <mg...@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 <mk...@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 <mg...@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
Re: Serialization warnings
Posted by Michael Gentry <mg...@masslight.net>.
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 <mk...@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 <mg...@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 <mk...@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 <mg...@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 <mk...@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 <mg...@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 <mk...@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 <mg...@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
Re: Serialization warnings
Posted by Mike Kienenberger <mk...@gmail.com>.
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 <mg...@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 <mk...@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 <mg...@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 <mk...@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 <mg...@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 <mk...@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 <mg...@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
Re: Serialization warnings
Posted by Michael Gentry <mg...@masslight.net>.
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 <mk...@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 <mg...@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 <mk...@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 <mg...@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 <mk...@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 <mg...@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
Re: Serialization warnings
Posted by Mike Kienenberger <mk...@gmail.com>.
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 <mg...@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 <mk...@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 <mg...@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 <mk...@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 <mg...@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
Re: Serialization warnings
Posted by Michael Gentry <mg...@masslight.net>.
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 <mk...@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 <mg...@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 <mk...@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 <mg...@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
Re: Serialization warnings
Posted by Mike Kienenberger <mk...@gmail.com>.
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 <mg...@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 <mk...@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 <mg...@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
Re: Serialization warnings
Posted by Michael Gentry <mg...@masslight.net>.
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 <mk...@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 <mg...@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
Re: Serialization warnings
Posted by Mike Kienenberger <mk...@gmail.com>.
+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 <mg...@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