Jackson为什么要实现Serializable？答案

【问题标题】：Why does Jackson implement Serializable?Jackson为什么要实现Serializable？
【发布时间】：2021-06-09 10:13:58
【问题描述】：

built-in serialization of Java objects to their binary forms 现在在大多数项目中并不常见，它们倾向于使用 ProtoBufs、XML、JSON 等在服务器之间进行数据传输。 CORBA 和所有似乎都属于 2000 年代的项目。老实说，我只见过它实现过一次（在十年前的一个 J2EE 项目中），它看起来有点古怪。不过，每次 IntelliJ 抱怨某些课程中缺少 serialVersionUID 时，我仍然会想起整个 Serializable 事情！如今，这主要发生在我使用 Jackson 处理 JSON 序列化/反序列化时，因为它具有类型注释，表明某些类必须实现 Serializable。通常像

StdDeserializer<T> extends JsonDeserializer<T> implements Serializable, Gettable

（我没有看到T需要可序列化，只有序列化器？）

现在，我不明白的是，当我们现在主要处理 JSON 和 XML 时，为什么还要处理二进制 Java 对象序列化的概念。为什么 Jackson（和其他“新”库）会选择处理这个问题？

我唯一的猜测是，这与 Jakcson 的客户端序列化的域类无关，但一些高级 JVM 使用可以在 JVM 或类似的东西之间传输正在使用的各种对象，这需要稳定的接口对于writeObject() 和readObject()。但我在这里真的如履薄冰。

【问题讨论】：

您的问题出在 intellij，而不是 java。没有必要实际定义一个serialversionid。如果你不使用内置序列化，你应该禁用 intellij 中的检查
不过，这不是我的问题。我在问杰克逊，尽管 IntelliJ 可能会抱怨 :) 我只是被提醒这个接口仍然存在。
这很难回答，因为只有这个确切的class 的开发者才能提供他们这样做的为什么的见解。
长期以来，标准的建议基本上是让所有东西都可以序列化，只要它可以轻松完成。如今，情况看起来有所不同，请参阅this related question。但是，作为库提供者，您需要考虑是否要支持使您的类可序列化。能够保存序列化程序的状态可能看起来不是一个超级常见的用例，但它可能很容易实现。似乎创作者认为它值得。
根据JavaDocs of StdDeserializer 判断，Serializable 在 2.0 中不存在，但在 2.1 中存在。您可能会挖掘导致添加它的更改请求。

标签： java serialization

【解决方案1】：

在查看为StdSerializer 课程介绍此问题的提交后，我与Jackson 的维护者Tatu Saloranta 联系，关于这个问题，他详细回答了！在此处发布his answer：

事实上，这是作为用户请求而来的，我记得有可能有 2 个用例可能有用。其中第二个可以有点资格“在不同的JVM之间移动对象”。我本来有同意这些用例似乎都不特别普通模式，fwtw。

第一个有点异国情调（可能与也可能不相关）这一点）适用于Android用例的解冻/解冻（或其他当应用程序进入后台模式时调用它，返回，wrt XmlMapper （XML 支持的 ObjectMapper）——如果是这样，性能显然是很多的与重新创建映射器相比，如果使用 JDK 序列化更好实例。不知道是不是还是这样。

第二，更广泛适用的用例将用于平台，如 Spark（或 Hadoop，也许是 Flink/Apache Beam），其中一个协调器节点可能想以某种方式配置映射器，然后将其发送到初始化为特定设置的工作节点（还包括注册模块，这就是序列化器/反序列化器的方式相关的）。如果是这样，性能不是关键，而是准确的能力要使用的配置。

但是试图使/保持（反）序列化器 JDK 可序列化是一个拖累和我很高兴我可以从 Jackson 3.x 中删除（无论何时被释放:) )。 ObjectMappers 仍然是 JDK 可序列化的，但是不需要许多/大部分内部组件。这个做完了通过改变映射器的构建方式，我可能不应该在这里太深入细节。 :)

【讨论】：