You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Luther Baker <lu...@gmail.com> on 2009/04/11 15:45:31 UTC
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
Posted by Brill Pappin <br...@pappin.ca>.
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 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 <jo...@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-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
Re: serialVersionUID
Posted by Luther Baker <lu...@gmail.com>.
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 <pi...@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 <jo...@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-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
> >
>
Re: serialVersionUID
Posted by Jim Pinkham <pi...@gmail.com>.
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 <jo...@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-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: serialVersionUID
Posted by John Krasnay <jo...@krasnay.ca>.
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-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: serialVersionUID
Posted by Johan Compagner <jc...@gmail.com>.
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 <es...@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
> <jc...@carmanconsulting.com> wrote:
> > On Sun, Apr 12, 2009 at 1:46 PM, Ben Tilford <be...@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-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: serialVersionUID
Posted by Eduardo Nunes <es...@gmail.com>.
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
<jc...@carmanconsulting.com> wrote:
> On Sun, Apr 12, 2009 at 1:46 PM, Ben Tilford <be...@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-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: serialVersionUID
Posted by James Carman <jc...@carmanconsulting.com>.
On Sun, Apr 12, 2009 at 1:46 PM, Ben Tilford <be...@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-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: serialVersionUID
Posted by Brill Pappin <br...@pappin.ca>.
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
> <ee...@gmail.com>wrote:
>
>>> 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-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
Re: serialVersionUID
Posted by Ben Tilford <be...@gmail.com>.
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
<ee...@gmail.com>wrote:
> > 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-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: serialVersionUID
Posted by Eelco Hillenius <ee...@gmail.com>.
> 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-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: serialVersionUID
Posted by Ben Tilford <be...@gmail.com>.
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 <lu...@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
Posted by Luther Baker <lu...@gmail.com>.
>
> 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
Posted by John Krasnay <jo...@krasnay.ca>.
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-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: serialVersionUID
Posted by Luther Baker <lu...@gmail.com>.
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 <jo...@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-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: serialVersionUID
Posted by John Krasnay <jo...@krasnay.ca>.
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-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: serialVersionUID
Posted by John Krasnay <jo...@krasnay.ca>.
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 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
Bingo!
jk
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: serialVersionUID
Posted by Daniele Gariboldi <da...@gmail.com>.
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:
<<There are many valid reasons for using serialVersionUID (protecting
against compiler differences, establishing backward serialization
compatibility, etc.), but performance is not one of them.>>
I think the decision to not set (and manage) serialVersionUID should be
reconsidered. Java applications are going to run for longer time and survive
code modification and recompilation using runtime deployment (as of OSGi)
and move from VM to VM , perhaps different versions and brands of VM, around
Google (and Amazon, SUN, etc.) datacenters.
I found http://mindprod.com/jgloss/serialization.html#SERIALVERSIONUID this
article interesting, when it says serialVersionUID is checked in all
hierarchy classes. This could be a problem for the wicket style of using
anonymous classes (ex: new Link("link"){...) because as far as I understand
this classes too should declare a serialVersionUID, to recover from
serialization on another (different) VM, and that would be really painfull
and code-cluttering.
If I'm right, the best I can think of is a code instrumentation (suffice at
compile or deply time) to force anonymous classes declaring only methods to
have serialVersionUID = 1L. This way you keep the code clean: you launch
this step just after developing and before deploying in your cloud (or OSGi
environment).
What do you think ? Does such a problem exists ? And if I'm correct, any
other ideas ?
Brill Pappin wrote:
>
> 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 <
>> adrianosf@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-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>
>
>
>
--
View this message in context: http://www.nabble.com/serialVersionUID-tp23001300p23173010.html
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: serialVersionUID
Posted by Brill Pappin <br...@pappin.ca>.
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 <
> adrianosf@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-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
Re: serialVersionUID
Posted by Luther Baker <lu...@gmail.com>.
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 <
adrianosf@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-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: serialVersionUID
Posted by Adriano dos Santos Fernandes <ad...@uol.com.br>.
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-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: serialVersionUID
Posted by Brill Pappin <br...@pappin.ca>.
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-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
Re: serialVersionUID
Posted by Adriano dos Santos Fernandes <ad...@uol.com.br>.
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-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: serialVersionUID
Posted by Brill Pappin <br...@pappin.ca>.
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