Scott,
From: "Scott Gray" <scott.g...@hotwaxmedia.com>
Hi Jacques,
I'm not going to sit here and pretend to be some sort of expert on the
subject, I was merely correcting a statement which I knew
to be false.
I was not false but badly expressed :p. I wanted to speak about the peculiar
case of versionning with serialisation (actually that
what serialVersionUID is all about).
Because it's the only case that may introduce an issue. The implicit mechanism
should work in most cases but is not guaranteed[1][2]
That said, it is my understanding that java serialization always uses
versioning on objects that implement the Serializable
interface, the only choice is whether it is implicit (done by the compiler) or
explicit (hand coded or autogenerated by an IDE).
The discussion in hand is about what that choice should be implicit or
explicit, with both options appearing to have some
downsides. In regards to that decision I really have nothing of value to add
:-)
I agree with David, let the compiler deals with it and if someone has a real need then she/he should use serialVersionUID in her/his
code.
So I'd prefer to put @SuppressWarnings("serial") everywhere (even in the
cases I reported serialVersionUID is currently used ) and
forget about it
I learnt one thing : Runtime computation of the serial version UID hash is
expensive in terms of performance
One question remains : should we continue to "support"(include) Shark ?
Jacques
[1]<<As a general rule, it's always a good idea to declare explicit serial
version UID values for serializable classes. There are
two reasons for doing that:
a.. Runtime computation of the serial version UID hash is expensive in terms
of performance. If you don't declare a serial version
UID value, then serialization must do it for you at runtime.
b.. The default serial version UID computation algorithm is extremely
sensitive to class changes, including those that might
result from legal differences in compiler implementations. For instance, a
given serializable nested class might have different
default serial version UID values depending on which javac was used to compile
it. That's because javac must add synthetic class
members to implement nested classes, and differences in these synthetic class
members are picked up by the serial version UID
calculation. >>
c.. http://java.sun.com/developer/JDCTechTips/2001/tt0306.html
[2] http://en.wikipedia.org/wiki/Serialization#cite_ref-2
Regards
Scott
On 5/11/2009, at 7:49 PM, Jacques Le Roux wrote:
Hi Scott,
Actually I did not well express myself yesterday night. I was speaking about
serialisation *and* versionning.
As Bob explained, we don't need to put serialVersionUIDs as long as we are not
concerned by versionning.
BTW, the only places we currently have serialVersionUIDs are
AuthenticatorException and a bunch in Shark (BTW I wonder if we
should keep Shark in OFBiz ?)
I wonder if in RMI, session replication and session persistence will ever
use versionning ? I mean you use it in a context
where you will not change classes and compile, isn'it ?
Now I wonder how you envision to use serialisation versionning with runtime
data for persisted services. Could you elaborate
please ?
Anyway all above is not really related with @SuppressWarnings("serial") which
is only a convenient way to hide a warning and
does not block any future uses of serialisation versionning.
Jacques
From: "Jacques Le Roux" <jacques.le.r...@les7arts.com>
Ha yes, I forgot about RMI and session replication, thanks Scott.
So this introduce san uncertainty about using @SuppressWarnings("serial") or
not because you have to consider how the class
will be used.
Maybe we should stay as we were and not put this annotation anywhere or very
carefully ?
For instance in the POS I don't expect any uses of RMI nor any points Scott's
outlined below, so I guess it's safe there.
And anway in case we need serialisation we can always remove the annotation
and seralise isn'it ?
Jacques
From: "Scott Gray" <scott.g...@hotwaxmedia.com>
FYI Jacques, we do use serialization and will in the future, RMI, session
replication, session persistence, runtime data for
persisted services, etc.
Regards
Scott
HotWax Media
http://www.hotwaxmedia.com
On 5/11/2009, at 11:43 AM, Jacques Le Roux wrote:
KISS : my opinion is that we don't use serialisation and should not in the future, so
@SuppressWarnings("serial") seems good
to me.
And I always remember being badly biteen by serialisation in Visual C ++ 10
years ago
When changing fields (adding or removing can't remember), it worked for
objects alone, but not when these objects were in a
CMap and you wanted to serialise all (list+its objects)
Jacques
From: "Bob Morley" <rmor...@emforium.com>
I do not disagree with the overall premise.
However, I believe that there is no "compiler handling" in this case. My
understanding (and I stand to be corrected) is that if we were to serialize
an object, have a new field added, and then attempt to deserialize it, it
will always throw an exception if we have not specified the serial number.
(I believe at runtime it will use reflection, determine the class definition
has changed, and throw the exception).
Contrast this to having a serial number on the class, where new fields (in
the same scenario) would be effectively ignored but the object would be
successfully deserialized.
Having said this, my guess is that we do not do much of this (perhaps job
sandbox?) so it might be much to do about nothing. I was more curious if
there was a discussion / lots of thought put into not specifying a serial
number and using the warning suppression.
Personally, I have no vested interest in doing it one way or another. I am
really looking for the best practice as I go through and clean- up other
warnings in the source code. Since our internal process has been to
generate the serial number, I thought it would be good to have a quick
dialog and see if we are doing the right thing or if we should make a
change.
David E Jones-4 wrote:
In this and in general I prefer not to manually or personally control
things that I know I am likely to mess up. In other words, I think
this is one case where it is likely that we will often forget to
update manual serial UIDs, even if some IDEs help with it.
I may be missing something, but isn't this better to let the compiler
handle?
-David
On Nov 3, 2009, at 8:24 AM, Bob Morley wrote:
Wondering if it makes sense for the best practice for serialized
classes to a
generated serial number instead of just suppressing the warning?
Currently
in Ofbiz there are lots of examples of the suppression in place but
only one
generated serial number
(org.ofbiz.common.authentication.api.AuthenticatorException).
My brief understanding is that Java will make use of the generated
serialVersionUID when it is determining if the definition of a class
has
changed for deserialization rather than using reflection.
We have been working on cleaning up warnings in the source code and
this is
one that I am just now considering for clean-up.
Thoughts?
--
View this message in context:
http://n4.nabble.com/Usage-of-SuppressWarnings-serial-tp361041p361041.html
Sent from the OFBiz - Dev mailing list archive at Nabble.com.
--
View this message in context:
http://n4.nabble.com/Usage-of-SuppressWarnings-serial-tp361041p361091.html
Sent from the OFBiz - Dev mailing list archive at Nabble.com.
