考虑以下 Java 异常类:

public class BarException extends RuntimeException {
    // [...]
}

public class FooException extends BarException {
    private static final long serialVersionUID = -5322002268075295537L;

    // [...]
}

如果我想更新继承层次结构以删除 BarException, ,使得 FooException 直接源自 RuntimeException, ,这是否需要更改 serialVersionUID 价值?

// FooException with updated inheritance hierarchy
public class FooException extends RuntimeException {
    private static final long serialVersionUID = ???;

    // [...]
}
有帮助吗?

解决方案 3

鉴于该规范不够清晰,足以引起混乱和争论,并且没有明确的答案出现,剩下的唯一选择就是相信经验证据。

以上述问题为例, FooException 源自 BarException 源自 RuntimeException, ,然后删除 BarException 从继承链中,我组合了一个示例应用程序来尝试各种组合的序列化和反序列化。

我得到以下结果:

只要我保留 serialVersionUID 不变,我可以成功序列化和反序列化原始的 FooException 作为更新的 FooException, 反之亦然。

以下注意事项适用:

  • 我使用的是 JDK 1.5.0_07,还没有在任何其他版本上尝试过。
  • FooException 具有类型的成员 intException, ,已成功反序列化。
  • BarException 不添加任何其他成员 RuntimeException.

其他提示

是。 “在层次结构中向上或向下移动类”根据,将导致与以前的序列化实例不兼容序列化规范

Java 1.5序列化规范建议从继承层次结构中删除类是兼容的更改,因此不需要更改 serialVersionUID

在反序列化为新的 FooException (直接从 RuntimeException 派生)时,将忽略序列化流中与 BarException 相关的任何额外信息。 )。

技术上是,但这取决于您的系统是否持久化序列化对象以及您是否控制如何部署新的重构代码。

如果你没有执行持久性,并且你将使用新版本的代码刷新整个部署,我认为不需要更改 serialVersionUID

许可以下: CC-BY-SA归因
不隶属于 StackOverflow
scroll top