Is serialVersionUID really required?

["Wang, Yuesong" <yw...@fedcsc.com>]

Hi,
 
In theory, all Serializable classes should have a serialVersionUID, but
to provide one to every annonymous inner class used everywhere in a
Wicket app is just too much. So I decided to turn off that warning in
Eclipse, and not to use serialVersionUID any more, but what is the
implication? For example, will I run into any problem during
deployment/undeployment? What about clustering?
 
Thanks,
 
Yuesong

Re: Is serialVersionUID really required?

[Johan Compagner <jc...@gmail.com>]

if you redeploy a new version
where you did some changes in components that would now generate another id
then the sessions that are on disk cant be loaded anymore
so you loose your sessions

if you had an id. And you dont change it because you want to be able to
deserialize
because you dont added a field or what ever and you know that the
deseralized object
works perfectly with the new object then it can be loaded in and you wont
loose sessions

johan



On Thu, Feb 14, 2008 at 5:23 PM, Wang, Yuesong <yw...@fedcsc.com> wrote:

> Johan,
>
> Thanks for the reply. Just need some further comfirmation.
>
> Here is my scenario:
> 1) The app is packaged in a single war.
> 2) No distributed deployment - everything is on the app server (Tomcat
> 6.0).
> 3) Only user agent is web browser. No remote client (RMI, java web start
> etc.).
> 4) Same JVM across all servers in cluster.
> 5) When deploying a new release, all servers will be
> stopped/undeployed/deployed/started at the same time.
>
> Is that enough to avoid potential serialization issues that may be
> caused by not supplying serialVersionUID?
>
> Yuesong
>
> -----Original Message-----
> From: Johan Compagner [mailto:jcompagner@gmail.com]
> Sent: Thursday, February 14, 2008 11:06 AM
> To: users@wicket.apache.org
> Subject: Re: Is serialVersionUID really required?
>
> not that importand
> it is just easier to cluster over different jvms (which doesnt happen a
> lot) but it is also easier to upgrade an existing code. Because the
> generated serialVersionUID does change for the most stupid ways (i guess
> they have to do that but most of the time i don;t care if i added a
> method)
>
> without the id serialization just breaks (can't deserialize) just way
> more often
>
> johan
>
>
>
> On Thu, Feb 14, 2008 at 4:09 PM, Wang, Yuesong <yw...@fedcsc.com>
> wrote:
>
> > Hi,
> >
> > In theory, all Serializable classes should have a serialVersionUID,
> > but to provide one to every annonymous inner class used everywhere in
> > a Wicket app is just too much. So I decided to turn off that warning
> > in Eclipse, and not to use serialVersionUID any more, but what is the
> > implication? For example, will I run into any problem during
> > deployment/undeployment? What about clustering?
> >
> > Thanks,
> >
> > Yuesong
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>

RE: Is serialVersionUID really required?

["Wang, Yuesong" <yw...@fedcsc.com>]

Johan,

Thanks for the reply. Just need some further comfirmation.

Here is my scenario:
1) The app is packaged in a single war.
2) No distributed deployment - everything is on the app server (Tomcat
6.0).
3) Only user agent is web browser. No remote client (RMI, java web start
etc.).
4) Same JVM across all servers in cluster.
5) When deploying a new release, all servers will be
stopped/undeployed/deployed/started at the same time.

Is that enough to avoid potential serialization issues that may be
caused by not supplying serialVersionUID?

Yuesong

-----Original Message-----
From: Johan Compagner [mailto:jcompagner@gmail.com] 
Sent: Thursday, February 14, 2008 11:06 AM
To: users@wicket.apache.org
Subject: Re: Is serialVersionUID really required?

not that importand
it is just easier to cluster over different jvms (which doesnt happen a
lot) but it is also easier to upgrade an existing code. Because the
generated serialVersionUID does change for the most stupid ways (i guess
they have to do that but most of the time i don;t care if i added a
method)

without the id serialization just breaks (can't deserialize) just way
more often

johan



On Thu, Feb 14, 2008 at 4:09 PM, Wang, Yuesong <yw...@fedcsc.com>
wrote:

> Hi,
>
> In theory, all Serializable classes should have a serialVersionUID, 
> but to provide one to every annonymous inner class used everywhere in 
> a Wicket app is just too much. So I decided to turn off that warning 
> in Eclipse, and not to use serialVersionUID any more, but what is the 
> implication? For example, will I run into any problem during 
> deployment/undeployment? What about clustering?
>
> Thanks,
>
> Yuesong
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

Re: Is serialVersionUID really required?

[Johan Compagner <jc...@gmail.com>]

not that importand
it is just easier to cluster over different jvms (which doesnt happen a lot)
but it is also easier to upgrade an existing code. Because the generated
serialVersionUID
does change for the most stupid ways (i guess they have to do that but most
of the time i don;t care if i added a method)

without the id serialization just breaks (can't deserialize) just way more
often

johan



On Thu, Feb 14, 2008 at 4:09 PM, Wang, Yuesong <yw...@fedcsc.com> wrote:

> Hi,
>
> In theory, all Serializable classes should have a serialVersionUID, but
> to provide one to every annonymous inner class used everywhere in a
> Wicket app is just too much. So I decided to turn off that warning in
> Eclipse, and not to use serialVersionUID any more, but what is the
> implication? For example, will I run into any problem during
> deployment/undeployment? What about clustering?
>
> Thanks,
>
> Yuesong
>