序列化存在一些风险,包括不兼容的更改。如果在被序列化的类中发生不兼容的更改,那么即使使用 static final long serialVersionUID 字段,我们也无法对其进行反序列化。
那么,序列化的替代方案是什么?XML ? 如果有任何选择,那么在现实世界的项目中是否有任何使用序列化?
序列化存在一些风险,包括不兼容的更改。如果在被序列化的类中发生不兼容的更改,那么即使使用 static final long serialVersionUID 字段,我们也无法对其进行反序列化。
那么,序列化的替代方案是什么?XML ? 如果有任何选择,那么在现实世界的项目中是否有任何使用序列化?
当然还有 Java 序列化的替代方案:XML(如您所述);JSON;protobuf;您愿意使用的其他任何东西。
所有这些都将面临一些不兼容更改的风险。我看不出其他方法有什么神奇之处。如果向对象添加新属性,则必须处理“鸭子类型”。如果您删除一个必需的属性,所有方法都会出现问题。
您似乎将序列化与数据格式混淆了-最好将它们分开。
广义上,有三种序列化:
自动化的、全面的、低级的——这很有用,因为它可以作为服务提供并且使用起来几乎不需要任何努力。但是,就其本质而言,它与语言/程序中使用的内部格式密切相关——如果发生变化,那么反序列化将是“困难的”。典型的例子是java和python提供的“原生”序列化;它对于程序状态的短期快照很有用。
自动化的、受限的、中等级别的——通常用于通信/互操作。这将不支持一种语言的所有功能,可能只允许保存简单的数据结构。如果这足够了,那么它是一个有用的中间地带,因为它可以自动化,但独立于语言的内部格式(但不一定独立于程序的细节)。典型的例子包括协议缓冲区、thrift 和 json 库(不是json 本身,它是一种数据格式......);显然,这对于通信和临时数据存储很有用。
“手工编码”,高级- 这需要更多的工作,并且可能会节省更少的信息,但旨在以独立于程序(或语言)中使用的内部格式的方式提取“重要部分”。示例包括 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).