java - 有理由使用真正的serialVersionUID吗？

Question

这个问题与以下问题完全相同:

Why generate long serialVersionUID instead of a simple 1L?

讽刺的是，Michael Bogswardt 也回答了。

<小时/>

Michael Bogswardt生成serialVersionUID的答案让我思考。是否有任何理由生成像 eclipse 和 IDEA 这样的正确的serialVersionUID(或者只是简单的serialver)？或者插入 1L 也同样好吗？

Answer 1

一旦你在其中写入了一个数字(任何数字)，当你对类进行破坏兼容性的更改时，你就有责任修改它(例如，更改 JavaDoc 不会破坏它，添加属性肯定会破坏它)。

如果您避免指定 serialVersionUID，javac 会在其中放置一些唯一的内容，例如类的哈希值。

什么时候重要？当您将内容序列化到磁盘并希望稍后使用不同版本的程序加载它时。或者当两个可能具有不同版本的实例需要通过线路交换序列化数据时。

如果您不使用实际的序列化，并且您的类只是因为继承了该接口(interface)而Serialized，那么避免使用serialVersionUID是最简单、最安全的事情。如果您确实序列化但并不真正需要与过去兼容，则同样，在这种情况下，避免该值是最安全的事情。

另一方面，如果您需要加载过去修订版生成的内容(无论是远程还是您自己，从磁盘上长期遗忘的文件中)，那么您需要拥有该值并非常小心地增加数字当(且仅当)您确实破坏了兼容性时。

在第二条评论后添加(罗宾):

Doesn't answer the actual question.

呃，对。我想这是一个:不，据我所知，实际数字没有任何意义，它只需要与以前的所有值不同，当它不再与它们兼容时。

Also, you should always declare a serialVersionUID for your Serializable classes

作为一般建议，我认为避免它是一个更好的解决方案:大多数时候你不需要与不同供应商的 JVM 交谈，你不需要反序列化很久以前的数据或实际需要的数据通过兼容性检查，大多数情况下序列化对象的生命周期都很短。

当然，对于不同的项目来说，这可能会非常不同，并且当您确实拥有长期存在的序列化对象时，您必须承担定义这些 UID 并正确维护它们的负担。

但是缺少 UID 意味着“快速失败，捕获错误”，而使用 1L(或任何其他常量)通常意味着“类发生变化，你不记得更新它，稍后会出现问题”，那么作为一般性建议，我认为第一个是更好的默认值。