在这种情况下，抑制警告不是比添加 serialVersionUID 更好的选择吗？答案

【问题标题】：Isn't suppressing warnings better option than adding serialVersionUID in this scenario?在这种情况下，抑制警告不是比添加 serialVersionUID 更好的选择吗？
【发布时间】：2011-11-04 13:25:46
【问题描述】：

Web 应用程序中的常见场景：

应用程序有很多类需要存储在 Session 中并且是可序列化的
开发人员收到一堆关于“Serializable 类未实现 serialVersionUID”的警告
开发者耸耸肩，点击 IDE 的“add serialversionUID”，问题就解决了吗？

原则上我不喜欢自动添加serialVersionUID，因为该解决方案本质上意味着

最重要的是，开发人员声明“我知道我的更改什么时候会破坏序列化，什么时候不会，并且想要控制它而不是 JVM”，而实际上他不知道这些事情并且不知道想要控制他们
添加 serialVersionUID = 6266256561409620894L 既混乱又丑陋（好吧，你可以使用 1L）

我了解在存在类兼容性问题的应用程序中添加 serialVersionUID，开发人员会积极考虑并理解相关问题。

在典型的 Web 应用程序中，类的序列化何时中断并不重要。部署新版本时，可能会破坏一些无关的序列化会话，但这通常不是问题（很少有应用程序真正正确处理序列化会话的版本兼容性）。

底线：建议“始终在源文件中明确定义 serialVersionUID”不是很简单吗？

【问题讨论】：

标签： java serialization serialversionuid

【解决方案1】：

我同意你的观点，并在我当前的项目上做同样的事情：这个警告在编译器选项中被完全禁用。

【讨论】：

【解决方案2】：

你完全正确。如果您了解它的实际作用，并且确信这是正确的做法，您应该只添加一个 serialVersionUID。您显然了解它的实际作用，并且确信它不是正确的做法，所以不要添加它。

我看到很多程序员反射性地添加了一个serialVersionUID，因为它关闭了编译器并且不涉及添加@SuppressWarnings。这是错误的做法，他们是坏人。

底线：“始终在源文件中明确定义 serialVersionUID”的建议并不简单，它完全是错误的。

【讨论】：

【解决方案3】：

不确定您是否在询问在源代码中定义 serialVersionUID 的建议有多少水，或者只是说提供该类不需要序列化，如果它更好地规避通过直接抑制它或无论如何都不情愿地定义一个 serialiVersionUID 来发出警告。

这两个选项（添加 serialVersionUID 和禁止警告）是两个不同的东西。首先是通过更改类的版本来促进正确的序列化，其次是更改类时不进行序列化。它们不可互换 - 因此程序员在两者之间做出选择时必须选择适合设计要求的一个 - 而不是哪个简单。

【讨论】：

没错。如果类不需要是可序列化的，为什么还要实现 Serializable 呢？
因为 HttpSession 不需要支持存储不可序列化的对象？我们希望能够将我们的对象存储在会话中，但我们并不关心在部署新版本时会话是否中断。

【解决方案4】：

不提供serialVersionUID 几乎不是一个好主意。

如果省略它，对类的最轻微更改就会使其与之前的序列化不兼容，并且会出现序列化异常。
如果您提供它并稍后以与对象序列化规范的对象版本控制部分兼容的方式更改类，它可以工作，因此您已经领先。这涵盖了很多情况：具体来说，它涵盖了所有种情况，其中唯一改变的是方法。
如果您以与该规范不兼容的方式更改类，您将获得序列化异常，然后您可以解决它。

这些情况甚至没有一点可比性。自动对象版本控制丝毫不关心方法或最常见的可序列化字段更改情况。依赖默认的serialVersionUID计算排除了Object Versioning涵盖的很多情况。

【讨论】：

这可能都是正确的，但没关系，如果我们不关心使类不兼容的更改。如果这不重要，我们仍然需要使类 Serializable 以将它们存储在 HttpSession、serialVersionUID 和关于它的警告只是噪音。