4

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

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

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

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

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

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

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

4

4 回答 4

1

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

于 2011-08-26T13:52:55.330 回答
1

不提供 serialVersionUID 很少是一个好主意。

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

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

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

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

于 2011-08-27T02:31:09.140 回答
1

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

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

于 2011-08-26T14:01:49.693 回答
0

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

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

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

于 2011-08-26T13:59:52.030 回答