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
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
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
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*?
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
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
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).
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
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
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
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
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
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
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
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
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
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
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
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
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,
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
21 matches
Mail list logo
