3

序列化存在一些风险，包括不兼容的更改。如果在被序列化的类中发生不兼容的更改，那么即使使用 static final long serialVersionUID 字段，我们也无法对其进行反序列化。

那么，序列化的替代方案是什么？XML ? 如果有任何选择，那么在现实世界的项目中是否有任何使用序列化？

4

3 回答 3

3

当然还有 Java 序列化的替代方案：XML（如您所述）；JSON；protobuf；您愿意使用的其他任何东西。

所有这些都将面临一些不兼容更改的风险。我看不出其他方法有什么神奇之处。如果向对象添加新属性，则必须处理“鸭子类型”。如果您删除一个必需的属性，所有方法都会出现问题。

于 2012-04-15T17:58:49.883 回答
2

您似乎将序列化与数据格式混淆了-最好将它们分开。

广义上，有三种序列化：

  1. 自动化的、全面的、低级的——这很有用，因为它可以作为服务提供并且使用起来几乎不需要任何努力。但是，就其本质而言，它与语言/程序中使用的内部格式密切相关——如果发生变化，那么反序列化将是“困难的”。典型的例子是java和python提供的“原生”序列化；它对于程序状态的短期快照很有用。

  2. 自动化的、受限的、中等级别的——通常用于通信/互操作。这将不支持一种语言的所有功能，可能只允许保存简单的数据结构。如果这足够了，那么它是一个有用的中间地带，因为它可以自动化，但独立于语言的内部格式（但不一定独立于程序的细节）。典型的例子包括协议缓冲区、thrift 和 json 库（不是json 本身，它是一种数据格式......）；显然，这对于通信和临时数据存储很有用。

  3. “手工编码”，高级- 这需要更多的工作，并且可能会节省更少的信息，但旨在以独立于程序（或语言）中使用的内部格式的方式提取“重要部分”。示例包括 docbook 或打开文档（jaxb 在默认情况下提供对 close-to-(1) 的支持相当不错，但在允许 close-to-(3) 时要小心）；这对于长期数据归档很有用，并且通常与“官方”规范相关联。

与上述不同的是用于对序列化数据进行编码的数据格式。我相信您可以在 xml 中实现上述所有内容；json 倾向于在 (2) 处使用。

anyway, to answer the question - (1) has the problems you note. if (2) is sufficient, then it is a simple solution (but still suffers from some of the problems of (1) if data structures within the program change); otherwise you need to do the extra work implied by (3).

于 2012-04-15T23:32:36.300 回答
1

答案取决于你的目标。如果您在 Java 进程之间发送数据，则默认的 Java 序列化机制可能会正常工作。

然而，对于存储数据，尤其是人们可能想要查看或编辑的数据，Java 序列化机制不太适合。

当需要人类可读/可编辑的输出时，我非常喜欢有许多很棒的基于 XML 的 java 序列化库。

两个很棒的是：XStream和JAXB

于 2012-04-15T17:57:13.147 回答