Isn't suppressing warnings better option than adding serialVersionUID in this scenario?

A common scenario in web applications:

• application has lots of classes that need to be stored in Session and are Serializable
• developer gets a bunch of warnings about "Serializable class does not implement serialVersionUID"
• developer shrugs and clicks on IDE's "add serialversionUID" and problem is solved?

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

• most importantly developer states "I know when my changes break serialization and when they do not, and want to control that instead of JVM", when in fact he does not know those things and does not want to control them
• adding serialVersionUID = 6266256561409620894L is confusing and ugly (ok, you can use 1L)

I understand adding serialVersionUID in an application where class compatibility is an issue and developers actively take that into consideration and understand related issues.

In a typical web application it's not very important when the serialization of classes breaks or not. When a new version is deployed, some extraneous serialized sessions may be broken but this is usually not a problem (and few applications a开发者_如何转开发ctually properly handle version-compatibility of serialized sessios).

Bottom line: isn't advice "Always define the serialVersionUID explicitly in your source files" simplistic?

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

Not sure if you are asking about how much water the advice to defne serialVersionUID in source code holds , or are simply saying that provided the class is not required to be serialized , if it better to circumvent the warning by directly suppressing it or by unwillingly defining a serialiVersionUID anyway.

The two options ( adding serialVersionUID and suppressing warnings ) are two different things. First is to facilitate proper serialization with changing versions of classes and second is no serialization for changing classes. They are not interchangeable - so a programmer when making a choice between the two has to choose the one that suits the design requirements - rather than which is simple.

It is rarely a good idea not to provide a serialVersionUID.

• If you omit it, the slightest change to the class makes it incompatible with prior serializations and you get serialization exceptions.

• If you provide it and later change the class in a way that is compatible with the Object Serialization Specification, Object Versioning section, it works, so you are already ahead. And this covers a lot of cases: specifically it covers all cases where the only thing that has changed is a method.

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

The situations aren't even slightly comparable. The automatic Object Versioning doesn't care about methods in the slightest or about the most common cases of changes to serializable fields. Relying on the default serialVersionUID calculation excludes many cases that Object Versioning covers.

You are absolutely right. You should only add a serialVersionUID if you understand what that actually does, and are confident that it is the correct thing to do. You evidently understand what it actually does, and are confident that it is not the correct thing to do, so don't add it.

I see a lot of programmers reflexively adding a serialVersionUID because it shuts the compiler up and doesn't involve adding a @SuppressWarnings. This is the wrong thing to do, and they are bad people.

Bottom line: the advice "Always define the serialVersionUID explicitly in your source files" is not simplistic, it is flat-out wrong.