Java 番石榴不可变集合的序列化是否稳定？

有人警告我不要在序列化通信中使用的对象中使用Guava immutable collections，因为如果一端的Guava版本被更新，可能会出现序列化版本不兼容的问题。这是一个合理的担忧吗？

是的，这是一个合理的担忧

从番石榴项目主页(http://code.google.com/p/guava-libraries/):

所有对象的序列化形式都可能发生更改。不要保存这些内容，并假设它们可以被库的未来版本读取

---

如果您使用的是Java本机序列化，那么Guava不是一个好的选择。

让我们给出一些观点

序列化最突出的用途是：

在应用程序运行之间存储数据

在客户端和服务器之间发送数据

如果您控制客户端和服务器上使用的是哪个Guava版本，那么Guava对于应用程序2来说是完全合适的。此外，虽然Guava不能保证Guava版本之间序列化的一致性……但实际上，序列化的表单不会经常更改

另一方面，让我来解释一下为什么Guava不能保证序列化表单的一致性。我在Guava版本9和10之间更改了ImmutableMultiset的序列化形式，原因是我需要重构东西，以便将ImmutableSortedMultiset添加到immutable集合中。你可以自己看到变化。在保持序列化表单的一致性的同时尝试进行同样的重构几乎肯定需要额外的笨拙的破解，这与Guava团队的理念背道而驰。（这可能是由一个比我更专业的程序员完成的，但我仍然声称这不会是微不足道的。）保证长期的序列化兼容性需要付出惊人的努力，正如在中所讨论的，Kevin指出：

试图提供 跨版本兼容性使事情变得更加困难和复杂 我们在番石榴开始之前就放弃了

贾里德：

根本的问题仍然存在：确保序列化的表单 所有番石榴版本之间都兼容。那是我当时的一个目标 致力于Google Collections 1.0，但后来我放弃了这个目标 认识到它的困难。实现和测试跨版本 兼容性不值得这么做

---

最后，我要指出的是，番石榴在谷歌内部被广泛使用，而且管理得相当好

这对于任何类来说都可能是一个问题——你希望库的版本在发送端和接收端都是相同的。如果你不能控制在通信的两端使用哪个版本，那就“不是一个好选择”。这太糟糕了。不可变集合现在应该是稳定的。他们为什么要更改序列化的表单？在不同版本的数据结构之间保持序列化的兼容性真的很难。请参阅本文后面的一些消息，了解原因。