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
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
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
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
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
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
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
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
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
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
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
apps
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
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
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
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
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
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
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
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
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
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
28 matches
Mail list logo
