SerialVersionUID's do not change each time you compile a class - they
are calculated by the JVM based on various aspects of the class that may
affect it's serialization compatibility. So, if you don't change a class
and you're using the same JVM, the class's calculated serialVersionUID
will not change between builds.
If you declare a serialVersionUID, you should do it in your domain
classes rather than on Cayenne's generated superclasses (iow, I don't
see any good reason to use the Velocity template that was mentioned).
It's generally a good idea to maintain your own serialVersionUID for
classes that might be persisted in a session or stored on the client.
You then update the serialVersionUID only when you make changes that
would cause an incompatibility with old serialized objects. See
http://java.sun.com/j2se/1.5.0/docs/guide/serialization/spec/version.html#6678
Although you "bring everything down" between releases, are you sure that
session data is not being automatically written to disk on shutdown and
then reloaded on startup (this is the default behavior for Tomcat)? If
you truly don't care about objects from saved sessions being predictably
deserialized into new versions of your app (i.e. you are deleting or not
saving session data between releases) then I suppose you can safely
forget about serialVersionUID's altogether.
Like Chris said, this is a somewhat complex issue. However, if you
google on "java serialversionuid" and read the first few results, you'll
have a good enough handle on the topic to make the right decision. In
fact, if you just read the following links, you'll know more about this
than a lot of programmers out there ;)
http://www.javapractices.com/Topic45.cjp (this should be taken as a
recommendation, not a rule)
http://www.javaworld.com/javaworld/javaqa/2003-06/02-qa-0627-mythser.html
http://java.sun.com/j2se/1.5.0/docs/api/java/io/Serializable.html
-Ryan
Jeff de Vries wrote:
> Thanks for the quick response and insights into the issue!
>
> Just to make sure I understand -
>
> * If I don't set any serialVersionUID (and turn off the compiler
> warning), then each time I compile a class a new,
> automatically-generated serialVersionUID is created by the compiler
> (or some part of that pipeline). This creates the potential problem
> that if something was serialized out using a previous build, and then
> serialized in using a later build, there will be an error because the
> UID's won't match. For us, this wouldn't be a problem because we
> bring everything down when we deploy a new version, so there shouldn't
> be any old serialized data laying around (and if there was, we'd get
> an exception, which is what we'd want).
>
> * If I do set a serialVersionUID, then the assumption is made that my
> class will be smart enough to know how to convert older versions into
> newer versions. I assume your class has to implement some method to
> handle this situation.
>
> If the above is correct, I think I'll be removing the
> serialVersionUID's from our code. :-)
>
> Thanks again,
> Jeff de Vries
>
>
> Jeff de Vries wrote:
>> We recently moved to Eclipse 3.1 from Eclipse 3.0, and now we get
>> lots of warnings along the lines of "class <foo> does not have a
>> final, static serialVersionUID". Apparently, this is something Java
>> Serializable needs. Fortunately, Eclipse has a fast way of setting
>> these (double-click on warning, then Ctrl-1 to have a
>> serialVersionUID generated and inserted for you).
>>
>> My question has to do with Cayenne's auto-generated classes. Is
>> there a way to have serialVersionUID's automatically generated and
>> inserted into the auto classes? If not, how are other people
>> handling this issue?
>>
>> Thanks,
>> Jeff de Vries
>>
>
This archive was generated by hypermail 2.0.0 : Tue Feb 14 2006 - 13:34:31 EST