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

Question

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

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

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

• 最重要的是开发人员声明“我知道我的更改何时会破坏序列化，何时不会破坏序列化，并希望控制而不是JVM”，实际上他确实不知道这些事情而不是想控制他们
• 添加serialVersionUID = 6266256561409620894L令人困惑和丑陋（好吧，你可以使用1L）

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

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

底线：不是建议“总是在源文件中明确定义serialVersionUID”过于简单？

Answer 1

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

Answer 2

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

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

Answer 3

不提供serialVersionUID是一个好主意。

• 如果省略它，对该类的最轻微更改会使其与先前的序列化不兼容，并且会出现序列化异常。

• 如果您提供它并稍后以与对象序列化规范，对象版本控制部分兼容的方式更改类，则它可以工作，因此您已经领先。这涵盖了很多案例：特别是它涵盖所有案例，其中唯一改变的是方法。

• 如果您以与该规范不兼容的方式更改类，您将获得序列化异常，然后您可以解决它。

情况甚至没有可比性。自动对象版本控制并不关心可序列化字段更改的最轻微或最常见情况下的方法。依赖于默认的serialVersionUID计算，排除了对象版本控制所涵盖的许多情况。

Answer 4

你是对的。如果你了解它实际上做了什么，你应该只添加一个serialVersionUID，并确信这是正确的做法。你显然明白它实际上做了什么，并且确信不是正确的事情，所以不要添加它。

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

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