I wrote the wrong thing in my message. It should have been "generated superclass" rather than "generated subclass" -- hopefully it was still obvious we're talking about the generated class from the context.
While it's true that SerialVersionUID is not useful for the subclass's serialization, as far as I can tell, it is still necessary for the generated superclass class itself. The serialization process seems to serialize the superclass state based on their own SerialVersionUIDs -- that seems like the logical way to do it in any case as otherwise a subclass would have to know the implementation details for all superclasses. And in our specific case, where in the common case all of the state is in the generated class, it's the only place it really matters. Please correct me if I'm wrong. And I see now that the JIRA contains a working fix based on the ObjModel, which I think is a better solution than using the default serial generation. On Tue, Oct 4, 2011 at 10:25 AM, Durchholz, Joachim <joachim.durchh...@hennig-fahrzeugteile.de> wrote: >> -- SerialVersionUID seems to matter on the generated subclass, >> especially since this is where all of the state of CayenneDataObject >> exists. But I can only infer this -- I cannot find a specific >> statement. [1] [2] > > I can ;-) > >> [1] >> http://download.oracle.com/javase/1,5.0/docs/api/java/io/Serializable.html > > Last sentence on the page: > > "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." > > Actually, I slightly disagree with that sentence: a class could build its > SerialVersionUID working off the superclass' SerialVersionUID. > But the serialization mechanism itself does not use superclass > SerialVersionUIDs AFAIK. > > Regards, > Jo >
