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: | David E Jones (de...@me.com) | |
| Date: | Nov 3, 2009 12:27:44 pm | |
| List: | org.apache.ofbiz.dev | |
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.