Use the serialVersionUID or suppress warnings?
I want to create a class that, for example, extends HttpServlet? My compiler warns me that my class should have a serialVersionUID. If I know that this object will never be serialized, should I define it or add an annotation to suppress those warnings?
What would you do and why?
I don't know Java best practices, but it occurs to me that if you are claiming that serialization will never happen, you could add a writeObject method which throws. Then suppress the warning, safe in the knowledge that it cannot possibly apply to you.
Otherwise someone might in future serialize your object through the parent class, and end up with a default serialized form where:
Adding an ID sounds like a bodge, since what you really want to do is not serialize. Expecting callers not to serialize your object means that you expect them to "know" when their HttpServlet is of your class. That breach of polymorphism is on your head for having a Serializable object which must not be serialized, and the least you can do is make sure unwary callers know about it.
If you do not plan to serialize instances, add a SuppressWarning.
A generated serial ID can be a bit dangerous. It suggests that you intentionally gave it a serial number and that it is save to serialize and deserialize. It's easy to forget to update the serial number in a newer version of your application where your class is changed. Deserialization will fail if the class fields have been changed. Having a SuppressWarning at least tells the reader of your code that you did not intend to serialize this class.
I refuse to be terrorized by Eclipse into adding clutter to my code!
I just configure Eclipse to not generate warnings on missing serialVersionUID.
链接地址: http://www.djcxy.com/p/23852.html