我对Java序列化/反序列化有一个奇怪的问题。
除了序列化的所有其他问题以及serialVersionUID的正确用法之外，这种行为对我来说是全新的：
一台机器上，我的软件在（openSuse 13.1）上运行，更新将Java版本切换为Java 8。 ），因为其中一个包含的类具有错误的serialVersionUID。奇怪的是，这些类是来自外部库的类，并且几个月没有更改（但没有硬编码的serialVersionUID字段）。
如果我在该计算机上切换回Java 7，则不会发生该错误。我可以在其他带有openSuse 13.1 + Java 8的计算机上重现该错误，但不能在具有Windows或其他具有Java 8（或Java 7）的Linux发行版（例如Ubuntu）的计算机上重现该错误。
在所有计算机上，都安装了官方的sun / oracle JRE软件包。
那么，有人在任何时候都面临过这个问题吗？我不认为这是Java 8中的错误，因为它仅发生在openSuse 13.1计算机上。但是，来自openSuse的人们如何将他们的系统弄乱，以至于Java将以与以前不同的方式对类进行哈希处理（因为Java尚未在新版本中更改该过程）？
编辑：
需要明确的是，引起问题的类来自外部库。它没有改变一个月。解决方案不能是定义serialVersionUID，因为该错误还有其他来源，并且仍然存在。而且我认为，它不会随此类停止，它将影响我使用的库中所有未定义serialVersionUID的类
编辑2：
这是确切的错误：
java.io.InvalidClassException: edu.uci.ics.jung.graph.util.Pair; local class incompatible: stream classdesc serialVersionUID = 7664847375082415686, local class serialVersionUID = -638192081897624765
在我可以测试的所有其他机器上，该类具有哈希的serialVersionUID 7664847375082415686，只有openSuse 13.1 + Java 8获得了-638192081897624765的结果
最佳答案
有人在任何时候都面临过这个问题吗？
您做得很好，没发现此问题。所有IDE都对带有serialVersionUID AFAIK的可序列化类发出警告。这是一个普遍的问题，或者更常见的是，人们对serialVersionUID进行硬编码，以便他们看不到它。注意：Eclipse和Oracle JDK为相同版本的Java产生不同的UID。
因为它仅发生在openSuse 13.1机器上。
这将非常令人惊讶。相同的Java版本应在每个OS上产生相同的serialVersionUID。
注意：您可以将serialVersionUID设置为所需的任何内容。例如说您需要读取具有给定serialVersionUID的对象，可以将其设置为期望的UID，它将尝试读取所需的任何版本。