Sylvain Wallez wrote:
Ugo Cei wrote:
Il giorno 20/nov/04, alle 10:34, Leszek Gawron ha scritto:
I've found some neat ant task:
http://serialver.sourceforge.net/serialver.html
Then go for it! I hate those warnings and was planning to remove some
of them myself, like unread local variables or declared exceptions
that are never thrown.
Mmmh... before putting serialVersionUID all over the place just because
Eclipse barfs, shouldn't we think a bit more about what fixing this
number actually means?
AFAIK, we need to specify this when a serializable class is subject to
evolutions and we want to ensure that serialized instances of an old
version of a class can be reloaded by a newer version of that same
class. If that constant isn't present, then the JVM will compute one
automatically from the class' structure.
So, if we fix these UIDs, that means that from there on we have to take
great care that future versions of these classes are
structure-compatible with older versions, i.e. no field renaming or
deletion, and no new field whose value is set up in the constructor.
So my feeling is that this could cause more harm than good (having a
serialization exception is better than some other obscure failure)
furthermore considering that Cocoon is not a system where serialized
objects are supposed to be long-lived. And in the hypothetical case
where that would be the case, then the relevant classes, and only these
ones, could have a serialVersionUID, with the appropriate warning in the
javadoc about the needed compatibility of future versions.
So my advice: disable the warning in Eclipse, and that's all!
So I did. I just was not aware of the consequences. Now that I know how
it works in more details I also think that this is a bad idea.
--
Leszek Gawron [EMAIL PROTECTED]
Project Manager MobileBox sp. z o.o.
+48 (61) 855 06 67 http://www.mobilebox.pl
mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
