Or if you use a cluster that somehow (would be bad practice i know) had different kinds of jvm's on them Because the generated uid is depended on the jvm
Also the generated takes to much stuff of the class when it generates, An inner class would already trigger again a different uid. and i my eyes the only thing that is important if you add an instance field (and you dont do your own serialization for that object) And that field shouldnt or cant be null (because if by default that field can be null then that is again no problem) So i like the default 1L because that means that many times it just works, And if you really think ok an older version of this class shouldnt be able de deserialize into this then you up with 1 johan On Mon, Apr 13, 2009 at 14:58, Eduardo Nunes <esnu...@gmail.com> wrote: > serialVersionUID is very important, especially if you deal with > serialized data saved to disk, db, javaspace or somewhere else. For > example, if you use JavaSpaces, you put objects there and you can > disconnect, update your application version, run it again, and your > objects will be there. If you don't take care of the serial version > uid you could have some serialization problems even if you didn't > change anything, just because the runtime generated uid is different > from the previous one. So, in doubt I suggest you to inform it, you > can put 1L and increase for each modification or use a IDE generated > version of it. > > On Mon, Apr 13, 2009 at 5:30 AM, James Carman > <jcar...@carmanconsulting.com> wrote: > > On Sun, Apr 12, 2009 at 1:46 PM, Ben Tilford <bentilf...@gmail.com> > wrote: > >> I've always seen it done as public. Anyways I checked the javadoc and > the > >> access modifier does not matter. > > > > IntelliJ IDEA generates them as private. > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > > For additional commands, e-mail: users-h...@wicket.apache.org > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > >
