在实现Serializable的类上使用serialVersionUID和@SuppressWarnings("serial")的优缺点是什么？

Question

这个问题一直是我团队中一些热烈讨论的主题.我个人的选择是使用

@SuppressWarnings("serial")

我的想法是,这意味着与使用相比,维护的东西要少一些

serialVersionUID

我是否正确认为使用它允许编译器生成UID,因此更有可能获取类的更改？

我最大的担心是,当他们改变课程时依赖开发人员更改UID更有可能导致无法预料的错误.

我的做法有什么陷阱吗？有没有其他人使用这些方法中的任何一个有好的或坏的经历？

Answer 1

归结为这个问题:

• 是否应该通过相同的代码或不同的代码读取和写入序列化的流？

"不同的代码"可能意味着几件事:

• 旧版本与新版本
• 两个独立的程序,可能有新旧库
• 更像这样的东西.

在这些情况下,您应该强烈遵守序列化合同 - 而这不仅仅是通过设置serialVersionUId- 通常您还必须覆盖序列化和反序列化的方法以应对不同的版本.

如果 - 另一方面 - 同一个程序读取和写入内容缓存之类的东西,并且该缓存可以在软件更新时从头开始重建 - 然后随意让您的生活尽可能简单.

在这些极端之间当然是各种各样的灰色阴影.

Answer 2

像往常一样，确定的答案在“ 有效的Java”一章中。

TL; DR。@SuppressWarnings("serial")除非您确实想序列化该类，否则使用就很好（并且对于消除警告很有用）。在这种情况下，您想要实际实现serialVersionUID并正确执行，在类中每次可能引起反序列化问题的更改之后重新生成（或至少更改）它。