[Cayenne-dev] Serialization warnings

+1 for doing this for the generate-always classes.

Undecided about the generate-once subclasses.

The subclasses would still only be generated once. I have no desire
to change that aspect.

Thanks,

mrg

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"

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

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.

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

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.

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

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.

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.

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

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

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.

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:

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

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

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

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

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

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

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?

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.

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

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

FYI - this is fixed in 3.2 for CayenneDataObject descendants (i.e. all but ROP classes) :

https://issues.apache.org/jira/browse/CAY-1851