Java序列化1.4与1.6

我有一个java程序必须编译为1.4，另一个程序可以是任何东西（1.4或1.6），这两个程序需要来回传递序列化对象。如果我在两个程序都能看到的地方定义了一个可序列化类，java的序列化还能工作吗，还是我只需要1.6-1.6或1.4-1.4？

确保要序列化的类定义并为

static final long serialVersionUID

分配一个值，这样就可以了

---

也就是说，通常我不会这么做。我的偏好是只在单个进程内使用普通序列化，或者在同一台机器上的两个进程之间使用普通序列化，并从同一jar文件中获取序列化类。如果不是这样，序列化为XML是更好、更安全的选择。

Java库类应具有1.4和1.6之间的兼容序列化形式，除非另有说明。Swing明确声明版本之间不兼容，因此如果您试图序列化Swing对象，那么您就运气不佳

---

您可能会遇到javac生成的代码略有不同的问题。这将更改

serialVersionUID

。您应该确保在所有可序列化类中显式声明UID。

以及

serialVersionUID

包结构必须保持序列化的一致性，因此如果在1.4中有

myjar.mypackage.myclass

，则在1.6中必须有

myjar.mypackage.myclass

在包结构的某个地方有Java版本或您的发布版本并不少见。即使在编译之间serialVersionUID保持不变，包结构也会导致在运行时引发不兼容的版本异常

顺便说一句，如果您在类中实现了

Serializable

，那么如果缺少

serialVersionUID

，您应该会收到编译器警告

在我看来（并且基于几年的痛苦经验），Java本机序列化充满了问题，如果可能的话应该避免，特别是因为有很好的XML/JSON支持。如果您必须以本机方式序列化，那么我建议您将类隐藏在接口后面，并在后台实现工厂模式，以便在需要时创建正确类的对象

---

您还可以使用此抽象来检测不兼容的版本异常，并在后台执行迁移对象中的数据所需的任何转换。

如果双方使用相同的jar文件，则大多数情况下都可以使用。但是，如果您使用相同包/模块/框架的不同版本（例如不同的weblogic JAR或某些“罕见”异常的扩展使用），则需要进行大量集成测试才能获得批准

否，JVM的不同版本不会破坏序列化本身

如果您正在序列化的某些对象来自Java运行时，并且它们的类发展不兼容，那么您将看到失败。大多数核心Java类对此都很小心，但在过去的一些包中存在不连续性

多年来，我成功地将序列化（在RMI的上下文中）用于运行不同版本Java运行时的不同机器上不同编译的类

---

我不想偏离最初的问题太远，但我想指出，无论格式如何，演化序列化类都需要小心。这不是Java序列化特有的问题。无论是用XML、JSON、ASN.1等进行序列化，您都必须处理相同的概念。Java序列化提供了一个相当清晰的规范，说明了什么是允许的，以及如何进行允许的更改。有时这是限制性的，有时有一个处方很有帮助。

我是唯一一个在跨语言/跨平台/跨类（可能会随时间变化）时从不信任序列化机制的人吗？如果性能不重要，我倾向于序列化为XML并返回…@Uni，通常，如果两个进程都从完全相同的jar中获取序列化类，例如当两个进程都在同一台机器上时，我只会在进程之间使用序列化。如果进程在不同的机器上，我会选择XML。如果不显式声明serialVersionUID，您可以从两个不同的编译器中获得关于不同版本的异常，使用完全相同的代码，使用完全相同的环境，使用完全相同的编译器。@Paul：我认为默认的serialVersionUID被很好地指定为类成员的函数。我从来没有看到过它的虚假变化。你能描述一个发生这种情况的场景吗？是的，这将是一个奇怪的编译器，而不是为用于计算serialVersionUID的数据添加随机性（虽然我相信技术上在规范范围内）。我也不认为这会有什么不同，但请阅读这里第4.6节的注释“计算对类细节高度敏感，这些细节可能会因编译器实现的不同而有所不同”——但如果这些细节保持不变，那么改变UID的编译器就很奇怪（但不一定不兼容）。