类更改（例如字段添加或删除）是否保持 Serialized 的向后兼容性？

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

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

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

我对 Java 序列化一无所知，除了这篇关于如何序列化的精彩文章不要用Java编程 http://thedailywtf.com/Articles/Serializalicious.aspx在处理序列化时。 正如我想象的(d)，serialVersionUID 在 Java 序列化中起着关键作用，这就是我需要您帮助的地方。

除了本文的示例（我知道这是糟糕的编码）之外，当我修改类后 Eclipse 要求更新该字段时，是否应该修改该字段？

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

最佳序列化的准则是什么？

谢谢。

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

public class Foo {
    private String bar;
}

然后我改为：

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

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

假设你有课MyClass并且您希望确保未来的序列化兼容性，或者至少确保您不会无意中更改其序列化形式。您可以使用Verify.assertSerializedForm() from GS Collections 测试实用程序 https://github.com/goldmansachs/gs-collections/blob/master/collections-testutils/src/main/java/com/gs/collections/impl/test/Verify.java在多数情况下。

首先编写一个测试来断言您的类具有serialVersionUID of 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());
}

现在测试将通过，直到您更改序列化形式。如果您意外破坏了测试（更改序列化形式），首先要做的是检查您是否已指定serialVerionUID在可序列化类中。如果您忽略它，JVM 会为您生成它，但它非常脆弱。

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

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

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

当您有意更改序列化形式时，您需要更新 Base64 字符串才能通过测试。当你这样做时，它是crucial你改变serialVersionUID同时。选择什么号码并不重要，只要它是您以前从未在课程中使用过的号码即可。约定将其更改为2L, then 3L等等。如果您从随机生成的serialVersionUID (like -7019839295612785318L在示例中），您仍然应该将数字改为2L因为它仍然是序列化形式的第二个版本。

注：我是 GS 系列的开发人员。