I'm suprised no one has mentioned the runtime cost of computing a default serialversionid which is avoided if a constant is supplied. I used to make it a habit for this reason.
This thread made me curious if that was really true, so I googled a bit and found this article<http://www.javaworld.com/javaworld/javaqa/2003-06/02-qa-0627-mythser.html>which found no such benefit, and suggests we needn't bother. I think I'll turn off the Eclipse warning instead. -- Jim. On Sat, Apr 11, 2009 at 10:50 PM, John Krasnay <j...@krasnay.ca> wrote: > On Sat, Apr 11, 2009 at 05:32:51PM -0400, Ben Tilford wrote: > > The purpose of the *public* static final long serialVersionUID is for > long > > term storage or situations where you may potentially have made > modifications > > to the class that make it incompatible with previous versions > (distributed > > apps/clustering). > > It only prevents trivial changes (e.g. adding a public method) from > breaking your serialization compatibility. You can still break the > compatibility even with a serialVersionUID, e.g. by renaming a field. > Besides, Wicket page maps are neither long-term storage nor remotely > communicated, so I don't really see the point of putting in the effort. > > > I'd say that its easier to just add it in case you ever > > need it, its only 1 line of code. > > Given Wicket's reliance on component inheritance, adding > serialVersionUID in every place Eclipse complains about it would amount > to hundreds of lines of code on my projects. Java code has enough noise > already. > > jk > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > >
