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.
