about serialVersionUID in all components
Hi all what are the side effects of setting serialVersionUID on all page classes and components private static final long serialVersionUID = 1L; i am developing an application which will be deployed on appengine appengine handle sessions by storing them in the memcache and data store as there is no local filesystem for its memcache everything must be Serializable, and as the session is stored in the datastore , your session may last for several weeks even if the web container expires it Ok, when i develop my classes may change a lot hence the auto serialVersionUID changes, making appengine complain as its session does not expires anyway , i think setting private static final long serialVersionUID = 1L; on every component will resolve it on appengine side, but ,what about wicket side? does it have any implications or side effects? thanks Joe
Re: about serialVersionUID in all components
We're doing exactly that all the time on our wicket/GAE apps and haven't run into problems. Only thing we had to change was: static references to components and ajax don't mix well, but one shouldn't do this anyway. regards On 8 May 2010 13:12, Joe Fawzy joewic...@gmail.com wrote: Hi all what are the side effects of setting serialVersionUID on all page classes and components private static final long serialVersionUID = 1L; i am developing an application which will be deployed on appengine appengine handle sessions by storing them in the memcache and data store as there is no local filesystem for its memcache everything must be Serializable, and as the session is stored in the datastore , your session may last for several weeks even if the web container expires it Ok, when i develop my classes may change a lot hence the auto serialVersionUID changes, making appengine complain as its session does not expires anyway , i think setting private static final long serialVersionUID = 1L; on every component will resolve it on appengine side, but ,what about wicket side? does it have any implications or side effects? thanks Joe - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: serialVersionUID
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
Re: serialVersionUID
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
Re: serialVersionUID
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
Re: serialVersionUID
I've always seen it done as public. Anyways I checked the javadoc and the access modifier does not matter. On Sun, Apr 12, 2009 at 1:56 AM, Eelco Hillenius eelco.hillen...@gmail.comwrote: The purpose of the *public* static final long serialVersionUID is for long Why do you stress *public*? private is the norm for serialVersionUID. Eelco - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: serialVersionUID
Nice. I think thats actually more important than we've been giving it credit for in this thread! - Brill Pappin On 12-Apr-09, at 12:51 AM, Luther Baker wrote: I don't know much about it ... but would something like Terracotta use/require/leverage the serialVersionUID for something not so obvious in normal, singly homed deployments? I think I understand that it helps confirm or explicitly 'version' components that might be working together or across, say, JVM boundaries - but it seems like, if not explicitly provided, a default value is built automatically and, unless I want an older version to work with a newer version, I am fine just letting that happen. In fact, unless I am really abiding by serialVersionUID rules (changing it explicitly - every time I make a relevant, corresponding change to the containing class) - I'm not really gaining any functionality that the runtime can't already do. In fact, unless rigorously maintained, it seems I could likely end up with two different compiled versions with identical, explicit serialVersionUIDs - which surely seems worse then leaving it alone? -Luther On Sat, Apr 11, 2009 at 10:56 PM, Adriano dos Santos Fernandes adrian...@uol.com.br wrote: Brill Pappin wrote: Actually i don't think a missing one will cause that to fail unless there are a lot of incompatible changes. Just one incompatible change of class stored in the session and it will not be deserialized. However... even if it does matter, *in no way* should anyone depend on a serialized session to store data if your app can't recover from a clean session, you have bigger problems than not adding a serialVersionId. Hum? What about stateful pages, which is the Wicket market? If you can control your serial IDs, you have the chance of write custom deserializers. That does not means you can't with an absent ID, but AFAIU just the inclusion of one field and it will change making the deserialization fail. Adriano - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org smime.p7s Description: S/MIME cryptographic signature
Re: serialVersionUID
It wouldn't because its not really meant as an accessible member of the class. It's used at a lower level and would be accessible regardless of the scope. - Brill Pappin On 12-Apr-09, at 1:46 PM, Ben Tilford wrote: I've always seen it done as public. Anyways I checked the javadoc and the access modifier does not matter. On Sun, Apr 12, 2009 at 1:56 AM, Eelco Hillenius eelco.hillen...@gmail.comwrote: The purpose of the *public* static final long serialVersionUID is for long Why do you stress *public*? private is the norm for serialVersionUID. Eelco - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org smime.p7s Description: S/MIME cryptographic signature
serialVersionUID
A quick question - is it generally acceptable to use private static final long serialVersionUID = *1L*; for most the anonymous inner class I create using Wicket? Specifically, I'm asking about using the value (-1). I've seen this idiom in the source but wasn't sure if there was some rational or serialization concerns I needed to be aware of before generally using (-1) everywhere. -Luther
Re: serialVersionUID
On Sat, Apr 11, 2009 at 08:45:31AM -0500, Luther Baker wrote: A quick question - is it generally acceptable to use private static final long serialVersionUID = *1L*; for most the anonymous inner class I create using Wicket? Specifically, I'm asking about using the value (-1). I've seen this idiom in the source but wasn't sure if there was some rational or serialization concerns I needed to be aware of before generally using (-1) everywhere. -Luther An arbitrary constant (1 or -1) works just as well as any other value. Personally, I've disabled that warning in Eclipse and I don't add serialVersionUID to any of my Wicket components. jk - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: serialVersionUID
Thanks John, Let me take this one step farther, just to clarify. I know that in a standard web application, the web container can Serialize user HttpSessions such that one can shut an application down and upon bringing it back up, HttpSession state is restored and, for instance, a user might not have to log back in. This functionality required us to implement Serializable for anything we wanted to store in a user's HttpSession. From your response, is it safe to say that Wicket doesn't use the HttpSession that way - or at least, doesn't store all these pages and their contents out to Session such that there is no requirement from Wicket to use a valid, unique serial id for all these anonymous classes? Including the PageStore or anything else native to Wicket internals? Is there anything, whatsoever that Wicket or Java webapps would require proper serial ids for? -Luther (I hope it's clear, I am intentionally being technical and trying to clarify whether or not such unique serial ids are necessary or required for some dark corner of Wicket functionality vs just not using them because they are a pain or simply can safely be ignored or even left out.) On Sat, Apr 11, 2009 at 12:59 PM, John Krasnay j...@krasnay.ca wrote: On Sat, Apr 11, 2009 at 08:45:31AM -0500, Luther Baker wrote: A quick question - is it generally acceptable to use private static final long serialVersionUID = *1L*; for most the anonymous inner class I create using Wicket? Specifically, I'm asking about using the value (-1). I've seen this idiom in the source but wasn't sure if there was some rational or serialization concerns I needed to be aware of before generally using (-1) everywhere. -Luther An arbitrary constant (1 or -1) works just as well as any other value. Personally, I've disabled that warning in Eclipse and I don't add serialVersionUID to any of my Wicket components. jk - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: serialVersionUID
On Sat, Apr 11, 2009 at 01:31:47PM -0500, Luther Baker wrote: Thanks John, Let me take this one step farther, just to clarify. I know that in a standard web application, the web container can Serialize user HttpSessions such that one can shut an application down and upon bringing it back up, HttpSession state is restored and, for instance, a user might not have to log back in. Yep. In my development environment (Tomcat) I can often restart without losing my session. This functionality required us to implement Serializable for anything we wanted to store in a user's HttpSession. From your response, is it safe to say that Wicket doesn't use the HttpSession that way No, it's not safe to say :-). Wicket does indeed serialize pages and puts them in the session. - or at least, doesn't store all these pages and their contents out to Session such that there is no requirement from Wicket to use a valid, unique serial id for all these anonymous classes? Including the PageStore or anything else native to Wicket internals? Is there anything, whatsoever that Wicket or Java webapps would require proper serial ids for? -Luther You don't need a serialVersionUID for serialization to work (and certainly not a unique one, or your plan for using 1L wouldn't very well). jk - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: serialVersionUID
You don't need a serialVersionUID for serialization to work (and certainly not a unique one, or your plan for using 1L wouldn't very well). Thanks. -Luther
Re: serialVersionUID
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). I'd say that its easier to just add it in case you ever need it, its only 1 line of code. On Sat, Apr 11, 2009 at 4:22 PM, Luther Baker lutherba...@gmail.com wrote: You don't need a serialVersionUID for serialization to work (and certainly not a unique one, or your plan for using 1L wouldn't very well). Thanks. -Luther
Re: serialVersionUID
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
Re: serialVersionUID
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 articlehttp://www.javaworld.com/javaworld/javaqa/2003-06/02-qa-0627-mythser.htmlwhich 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
Re: serialVersionUID
This has been a good thread. I seem to remember the warning became much more over-stated when Ganymede (Eclipse 3.4) was released. An avid of user of FindBugs, I like avoiding squiggly yellow lines so I did the same here - and generating a unique id sounds so much more llike the right thing to do so yes, I've been going out of my way to put these things everywhere. It seems I was incorrectly under the impression that the JVM required this serial id to serialize correctly. So at the very least, thanks @Jim for that article! Well, at any rate, that was fine and ignorable when it was a few classes here and there - specifically, anything I was persisting to the HttpSession. It really wasn't until I started using Wicket with such a strong OO sentiment that this issue has blossomed and really begun to annoy me. Those stinking things are everywhere! Touche! Unless I find good counterpoint, I'm going to turn off the warning as well. Thanks all, -Luther On Sat, Apr 11, 2009 at 10:14 PM, Jim Pinkham pinkh...@gmail.com wrote: 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
Re: serialVersionUID
Yes, its fine. you really only need to worry about that kind of thing when you are passing java serialized classes between VMs (as in RMI). In fact, you likely don't really even need to bother for Wicket, and you can turn off that check in Eclipse. - Brill Pappin On 11-Apr-09, at 9:45 AM, Luther Baker wrote: A quick question - is it generally acceptable to use private static final long serialVersionUID = *1L*; for most the anonymous inner class I create using Wicket? Specifically, I'm asking about using the value (-1). I've seen this idiom in the source but wasn't sure if there was some rational or serialization concerns I needed to be aware of before generally using (-1) everywhere. -Luther smime.p7s Description: S/MIME cryptographic signature
Re: serialVersionUID
Brill Pappin wrote: Yes, its fine. you really only need to worry about that kind of thing when you are passing java serialized classes between VMs (as in RMI). In fact, you likely don't really even need to bother for Wicket, and you can turn off that check in Eclipse. If you care about inability to maintain your users sessions after a redeploy, depending on your change, you would not do it. It serves for this purpose as well. Adriano - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: serialVersionUID
Yah, i used to always add it just for completeness, but I quickly realized its just a bunch of YAGNI junk i don't need cluttering up my code. Now i just turn it off. - Brill Pappin On 11-Apr-09, at 11:14 PM, Jim Pinkham wrote: 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 articlehttp://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 smime.p7s Description: S/MIME cryptographic signature
Re: serialVersionUID
Actually i don't think a missing one will cause that to fail unless there are a lot of incompatible changes. However... even if it does matter, *in no way* should anyone depend on a serialized session to store data if your app can't recover from a clean session, you have bigger problems than not adding a serialVersionId. - Brill Pappin On 11-Apr-09, at 11:45 PM, Adriano dos Santos Fernandes wrote: Brill Pappin wrote: Yes, its fine. you really only need to worry about that kind of thing when you are passing java serialized classes between VMs (as in RMI). In fact, you likely don't really even need to bother for Wicket, and you can turn off that check in Eclipse. If you care about inability to maintain your users sessions after a redeploy, depending on your change, you would not do it. It serves for this purpose as well. Adriano - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org smime.p7s Description: S/MIME cryptographic signature
Re: serialVersionUID
Brill Pappin wrote: Actually i don't think a missing one will cause that to fail unless there are a lot of incompatible changes. Just one incompatible change of class stored in the session and it will not be deserialized. However... even if it does matter, *in no way* should anyone depend on a serialized session to store data if your app can't recover from a clean session, you have bigger problems than not adding a serialVersionId. Hum? What about stateful pages, which is the Wicket market? If you can control your serial IDs, you have the chance of write custom deserializers. That does not means you can't with an absent ID, but AFAIU just the inclusion of one field and it will change making the deserialization fail. Adriano - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: serialVersionUID
I don't know much about it ... but would something like Terracotta use/require/leverage the serialVersionUID for something not so obvious in normal, singly homed deployments? I think I understand that it helps confirm or explicitly 'version' components that might be working together or across, say, JVM boundaries - but it seems like, if not explicitly provided, a default value is built automatically and, unless I want an older version to work with a newer version, I am fine just letting that happen. In fact, unless I am really abiding by serialVersionUID rules (changing it explicitly - every time I make a relevant, corresponding change to the containing class) - I'm not really gaining any functionality that the runtime can't already do. In fact, unless rigorously maintained, it seems I could likely end up with two different compiled versions with identical, explicit serialVersionUIDs - which surely seems worse then leaving it alone? -Luther On Sat, Apr 11, 2009 at 10:56 PM, Adriano dos Santos Fernandes adrian...@uol.com.br wrote: Brill Pappin wrote: Actually i don't think a missing one will cause that to fail unless there are a lot of incompatible changes. Just one incompatible change of class stored in the session and it will not be deserialized. However... even if it does matter, *in no way* should anyone depend on a serialized session to store data if your app can't recover from a clean session, you have bigger problems than not adding a serialVersionId. Hum? What about stateful pages, which is the Wicket market? If you can control your serial IDs, you have the chance of write custom deserializers. That does not means you can't with an absent ID, but AFAIU just the inclusion of one field and it will change making the deserialization fail. Adriano - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: serialVersionUID
The purpose of the *public* static final long serialVersionUID is for long Why do you stress *public*? private is the norm for serialVersionUID. Eelco - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Is serialVersionUID really required?
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?
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 [EMAIL PROTECTED] 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
RE: Is serialVersionUID really required?
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:[EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Is serialVersionUID really required?
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 [EMAIL PROTECTED] 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:[EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
