The serialVersionUID is used in JVM to determine the class type if the
signature is the same when unserializing. So if you don't have components
with the same package + classname combination - then no worries.
Žilvinas Vilutis
Mobile: (+370) 652 38353
E-mail: cika...@gmail.com
On Sat
l
>
> 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 me
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
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
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 wrote:
> serialVersionUID is very important, especially if you deal with
> serialized data saved
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
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
e 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 for serialVer
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 som
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*?
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 t
> 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
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 tog
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
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
*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
b
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
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 so
enefit, 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 wrote:
>
> > On Sat, Apr 11, 2009 at 05:32:51PM -0400, Ben Tilford wrote:
> > > The purpose of the *pub
-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
> &g
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 (di
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 cas
>
> 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
t 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
--
On Sat, Apr 11, 2009 at 12:59 PM, John Krasnay 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
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 ab
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
cross 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
>
>
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
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
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
31 matches
Mail list logo
