java - 字段添加或删除等类更改是否保持 Serializable 的向后兼容性？

Question

在您可能需要修改可序列化类并保持向后兼容性的情况下，我有一个关于 Java 序列化的问题。

我有深厚的 C# 经验，所以请允许我将 Java 与 .NET 进行比较。

在我的 Java 场景中，我需要使用 Java 的运行时序列化机制序列化一个对象，并将二进制数据存储在永久存储中以供将来重用这些对象。 问题是，在未来，类可能会发生变化。可以添加或删除字段。

除了这篇关于如何 not to program in Java 的精彩文章外，我对 Java 序列化一无所知。在处理序列化时。正如我想象的那样 (d)，serialVersionUID 在 Java 序列化中起着关键作用，这就是我需要您帮助的地方。

除了文章的示例(我知道这是错误的编码)，当我修改类后 Eclipse 要求更新它时，该字段是否不被修改？

我记得在 .NET 世界中，当我添加新字段时，我必须将 [OptionalField] 属性添加到该字段以获得向后兼容性，因此 CLR 在旧的序列化中不需要它数据。此外，当我需要弃用某个字段时，我必须只删除公共(public)方法而不是私有(private)字段。

最佳连载指南是什么？

谢谢。

[添加] 这是一个例子。假设我有 Foo 类

public class Foo {
    private String bar;
}

然后我改成:

public class Foo {
    private String bar;
    private Integer eggs;
}

这两个版本之间是否存在兼容性问题？如果我在编译“newFoo”时反序列化“oldFoo”，eggs 是否等于 null 或抛出异常？显然，我更喜欢第一个!!

Answer 1

假设您有一个类 MyClass，并且您希望确保后续的序列化兼容性，或者至少确保您不会无意中更改其序列化形式。您可以使用 GS Collections test utilities 中的 Verify.assertSerializedForm()在大多数情况下。

首先编写一个测试，断言您的类的 serialVersionUID 为 0L 并且序列形式为空字符串。

@Test
public void serialized_form()
{
  Verify.assertSerializedForm(
    0L,
    "",
    new MyClass());
}

运行测试。它会失败，因为字符串表示 Base64 编码并且永远不会为空。

org.junit.ComparisonFailure: Serialization was broken. <Click to see difference>

当您单击以查看差异时，您将看到实际的 Base64 编码。将其粘贴到空字符串中。

@Test
public void serialized_form()
{
  Verify.assertSerializedForm(
    0L,
    "rO0ABXNyAC9jYXJhbWVsa2F0YS5zaHVrbmlfZ29lbHZhLkV4ZXJjaXNlOVRlc3QkTXlDbGFzc56U\n"
      + "hVp0q+1aAgAAeHA=",
    new MyClass());
}

重新运行测试。它很可能会再次失败并显示类似这样的错误消息。

java.lang.AssertionError: serialVersionUID's differ expected:<0> but was:<-7019839295612785318>

将新的 serialVersionUID 粘贴到测试中以代替 0L。

@Test
public void serialized_form()
{
  Verify.assertSerializedForm(
    -7019839295612785318L,
    "rO0ABXNyAC9jYXJhbWVsa2F0YS5zaHVrbmlfZ29lbHZhLkV4ZXJjaXNlOVRlc3QkTXlDbGFzc56U\n"
      + "hVp0q+1aAgAAeHA=",
    new MyClass());
}

测试现在将通过，直到您更改序列化表单。如果您不小心破坏了测试(更改序列化形式)，首先要做的是检查您是否在 Serializable 类中指定了 serialVerionUID。如果您将其遗漏，JVM 会为您生成它并且它非常脆弱。

public class MyClass implements Serializable
{
  private static final long serialVersionUID = -7019839295612785318L;
}

如果测试仍然失败，您可以尝试通过将新字段标记为 transient 、使用 writeObject() 等完全控制序列化表单来恢复序列化表单。

如果测试仍然失败，您必须决定是查找并还原破坏序列化的更改，还是将您的更改视为对序列化形式的有意更改。

当您故意更改序列化形式时，您将需要更新 Base64 字符串以使测试通过。当您这样做时，至关重要同时更改 serialVersionUID 是很重要的。选择什么数字并不重要，只要它是您以前从未在类里面使用过的数字即可。惯例是将其更改为 2L，然后是 3L，依此类推。如果您从随机生成的 serialVersionUID(如 -7019839295612785318L 在示例中)，您仍应将数字更改为 2L，因为它仍然是序列化形式的第二个版本。

注意:我是 GS 集合的开发人员。