[ACCEPTED]-Use the serialVersionUID or suppress warnings?-serialversionuid

I don't know Java best practices, but it 17 occurs to me that if you are claiming that 16 serialization will never happen, you could 15 add a writeObject method which throws. Then 14 suppress the warning, safe in the knowledge 13 that it cannot possibly apply to you.

Otherwise 12 someone might in future serialize your object 11 through the parent class, and end up with 10 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 9 ID sounds like a bodge, since what you really 8 want to do is not serialize. Expecting callers 7 not to serialize your object means that 6 you expect them to "know" when their HttpServlet 5 is of your class. That breach of polymorphism 4 is on your head for having a Serializable 3 object which must not be serialized, and 2 the least you can do is make sure unwary 1 callers know about it.

If you do not plan to serialize instances, add 11 a SuppressWarning.

A generated serial ID 10 can be a bit dangerous. It suggests that 9 you intentionally gave it a serial number 8 and that it is save to serialize and deserialize. It's 7 easy to forget to update the serial number 6 in a newer version of your application where 5 your class is changed. Deserialization will 4 fail if the class fields have been changed. Having 3 a SuppressWarning at least tells the reader 2 of your code that you did not intend to 1 serialize this class.

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

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

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

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

I also added this method:

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

Hopefully 1 that's what Steve meant :)

Even if you know this object will be serialized 10 there is no need to generate serialVersionUID 9 because java will automatically generate 8 it for you and will automatically keep track 7 of changes so your serialization will always 6 work just fine. You should generate it only 5 if you know what you are doing (backward 4 serialization compatibility, manual change 3 tracking etc.)

So I would say suppressing 2 the warning is the best and safest solution 1 in most cases.

It is good to generate SVUID to every class implementing 6 serializable. The reason is simple. You 5 never know when it will be serialized by you 4 or by some 3rd party. There can be configured 3 a lot of services which will serialize servlets. For 2 every IDE exists plugin which generates 1 one or just use template and set svuid = 1L.

That warning drives me crazy, because every 4 time you subclass a Swing class, you know you're 3 never going to serialize it, but there is 2 that stupid warning. But yeah, I let Eclipse 1 generate one.

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

If you leave out a serialVersionUID java 13 will generate one for the class at compile 12 time (it changes with every compilation).

When 11 deserializing objects the serialVersionUID 10 of the deserialized object is compared to 9 that of the class in the jvm. If they are 8 different they are considered incompatible 7 and an Exception is thrown. This can happen 6 for instance after upgrading your program 5 and deserializing old classes.

I always use 4 1L for serialversionUID. It doesn't hurt 3 (compared to the default generated) and 2 it still leaves the option of breaking compatibility 1 later by incrementing the id.

It depends.

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

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

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

Please follow this link to get detailed 1 explanation: http://technologiquepanorama.wordpress.com/2009/02/13/what-is-use-of-serialversiouid/

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

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

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