10 messages in org.apache.ofbiz.devRe: Usage of @SuppressWarnings("serial")| From | Sent On | Attachments |
|---|---|---|
| Bob Morley | Nov 3, 2009 7:24 am | |
| David E Jones | Nov 3, 2009 12:27 pm | |
| Bob Morley | Nov 3, 2009 12:47 pm | |
| Jacques Le Roux | Nov 4, 2009 2:43 pm | |
| Scott Gray | Nov 4, 2009 3:02 pm | |
| Jacques Le Roux | Nov 4, 2009 3:55 pm | |
| Jacques Le Roux | Nov 4, 2009 10:49 pm | |
| Scott Gray | Nov 5, 2009 1:31 am | |
| Jacques Le Roux | Nov 5, 2009 2:30 pm | |
| Bob Morley | Nov 10, 2009 8:59 pm |
| Subject: | Re: Usage of @SuppressWarnings("serial") | |
|---|---|---|
| From: | Jacques Le Roux (jacq...@les7arts.com) | |
| Date: | Nov 4, 2009 3:55:40 pm | |
| List: | org.apache.ofbiz.dev | |
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" <scot...@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.