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?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.
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.
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.instances running different versions of the code? Are there are specific
use cases where Cayenne entities would be involved?
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.
