Joshua Szmajda wrote:
FYI I implement Serializable just by adding 'implements java.io.Serializable'. I let java take care of the serialVersionUID, etc. Works very well for me, and it's one less thing to keep track of :)
As I understand it, not providing your own serialVersionUID is a warning in JDK5, and will probably become an error at some point.
The value is a quick sanity check to answer the question "is this object still deserialisable?", and provides you with a clear mechanism to decide when you want to break binary compatibility at some point.
I worked recently with a system where the designers had made heavy use of the serialisation of Java objects into a database and hadn't set seialVersionUID, and a recurring problem was deserialisation errors after innocuous upgrades to the JDK, or to the code itself, it was a nightmare.
In the case of your JCS code, always cater for the chance that the cached object cannot be deserialised, especially if you are using a long lived cache like a disk cache. In theory, if you cannot deserialise the cached object, just dump the cached object as it will be useless to you, and pretend the object was never cached in the first place (JCS might already do this for you, not sure).
Regards, Graham --
smime.p7s
Description: S/MIME Cryptographic Signature
