Use the serialVersionUID or suppress warnings?

Question

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?

Answer 1

I refuse to be terrorized by Eclipse into adding clutter to my code!

I just configure Eclipse to not generate warnings on missing serialVersionUID.

Answer 2

Let Eclipse generate an ID. Quick and easy. Warnings are not to be ignored. Also saves you lots of trouble should you ever come to the point where the object /has/ to be serialized.

Answer 3

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:

• the form isn't compatible between different versions of your code.
• you've suppressed the warning that this is the case.

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.

Answer 4

It depends.

If you use different compilers to compile your source code multiple times, your compiled code could have different serializationIds that will break the serialization. Then you need to stick to a constant serializationId explicitly in your code. It must be static and final and per class (not inheritable).

However, if you always compile your code with a specific compiler and always deploy your code in one shot to all of your VMs, you probably need strict version checking and want to make sure that anytime there is only one version of you code running, in that case, you should just suppress the warning. So in case a VM is not deployed successfully and is running old version of your code, you probably expect an exception during serialization rather than quirk deserialized objects. This happens to be my case, we used to have a very very large cluster and we need strict version checking to find out any deployment issue.

Anyway, probably you should avoid serialization whenever possible since the default serialization is very slow compared to protocol buffers or thrift and does not support cross-language interoperability.

Answer 5

If you know your applications never serializes things, suppress the warning application-wide. This can be done using javac command line arguments:

javac -Xlint -Xlint:-serial *******

This way you will have all warnings except "serial". IDE-s and build tools like Maven/SBT/Gradle work fine with that.

Answer 6

Thanks @ Steve Jessop for his answer on this. It was 5 lines of code... hardly a hassle.

I added @SuppressWarnings("serial") just above the class in question.

I also added this method:

private void writeObject(ObjectOutputStream oos) throws IOException {
   throw new IOException("This class is NOT serializable.");
}

Hopefully that's what Steve meant :)