| Subject: | Usage of @SuppressWarnings("serial") | |
|---|---|---|
| From: | Bob Morley (rmor...@emforium.com) | |
| Date: | Nov 3, 2009 7:24:18 am | |
| List: | org.apache.ofbiz.dev | |
Refine Search
| 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: | Usage of @SuppressWarnings("serial") | |
|---|---|---|
| From: | Bob Morley (rmor...@emforium.com) | |
| Date: | Nov 3, 2009 7:24:18 am | |
| List: | org.apache.ofbiz.dev | |
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.

