Doesn't suppress warnings better than adding serialVersionUID in this scenario?

Question

Common scenario in web applications:

• the application has many classes that need to be stored in the session and are serializable
• developer receives a bunch of warnings about "Serializable class does not implement serialVersionUID"
• the developer shrugs and clicks on the IDE "add serialversionUID", and the problem is solved?

I don’t like automatically adding serialVersionUID in principle, since the solution essentially means that

• the most important states of developers: "I know when my changes interrupt serialization, and when not, and want to control it instead of the JVM," when in fact he doesn’t know these things and doesn’t want to control them
• adding serialVersionUID = 6266256561409620894L is confusing and ugly (ok, you can use 1L)

I understand that adding serialVersionUID to an application where class compatibility is a problem, and developers actively take this into account and understand the problems associated with it.

In a typical web application, this is not very important when the serialization of classes breaks or not. When a new version is deployed, some extraneous serialized sessions may be corrupted, but this is usually not a problem (and several applications actually handle compatibility with serial versions of sessios).

Bottom line: isn't the tip “Always define serialVersionUID explicitly in your source files” simplistic?

Answer 1

I agree with you and do the same in my current project: this warning is completely disabled in the compiler settings.

Answer 2

Not sure if you are asking about how much water advises define serialVersionUID in the source code or just saying that, provided that the class is not required for serialization, it is better to bypass the warning by directly suppressing it or reluctantly defining serialiVersionUID anyway.

Two options (adding serialVersionUID and suppressing warnings) are two different things. Firstly, to facilitate proper serialization with changing versions of classes, and secondly, not serialization to change classes. They are not interchangeable - therefore, when choosing between them, the programmer must choose the one that meets the design requirements, and not just.

Answer 3

It is rarely discouraged to provide a serialVersionUID.

• If you omit it, the slightest change in the class makes it incompatible with previous serializations, and you get exceptions for serialization.

• If you provide it, and then change the class in a way that is compatible with the specification for serializing objects, the section "Object Versions", it works, so you are ahead. And this applies to many cases: in particular, it covers all cases when the only thing that has changed is the method.

• If you change the class in a way that is incompatible with this specification, you will get an exception for serialization, and then you can eliminate it.

The situations are not even comparable. Automatic Object Versioning does not care about methods in the slightest or most common cases of changing serializable fields. Based on the default serialVersionUID calculation, it eliminates many of the cases that Object Versioning covers.

Answer 4

You are absolutely right. You should only add serialVersionUID if you understand what it actually does and are sure that this is the right thing. You obviously understand what this is actually doing, and you are sure that this is not the right thing, so do not add it.

I see many programmers reflexively adding a serialVersionUID because it closes the compiler and does not include the addition of @SuppressWarnings. This is the wrong job, and they are bad people.

Bottom line: the tip "Always define serialVersionUID explicitly in your source files" is not simplified, it is incorrect.