Re: serialVersionUID

Today we have Terracotta, OSGi, Google app engine and other cloud services. Reading this thread and http://www.javaworld.com/javaworld/javaqa/2003-06/02-qa-0627-mythser.html?page=3 Into the mist of serialization myths at: <> I think the decision to not set (and manage) serialVersionUID should b

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

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

Re: serialVersionUID

On Sun, Apr 12, 2009 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. IntelliJ IDEA generates them as private. - To unsubscribe, e-mail

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

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 s

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 wrote: > > The purpose of the *public* static final long serialVersionUID is for > long > > Why do you stress *public*? private is the norm f

Re: serialVersionUID

On Sat, Apr 11, 2009 at 11:51:47PM -0500, Luther Baker wrote: > > 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 ca

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 additiona

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

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 o

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 problem

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 comput

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 inabili

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

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

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 article

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 > app

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 eve

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

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

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

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).