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 序列化库。

两个很棒的是:XStreamJAXB

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