built-in serialization of Java objects to their binary forms 现在在大多数项目中并不常见，它们倾向于使用 ProtoBufs、XML、JSON 等在服务器之间进行数据传输。 CORBA 和所有这些似乎都属于 2000 年左右的项目。老实说，我只见过它实现过一次（十年前在一个 J2EE 项目中），而且看起来有点古怪。不过，每次 IntelliJ 抱怨 Serializable 在某些课程中丢失时，我仍然会想起整个 serialVersionUID 事情！如今，这主要发生在我使用 Jackson 处理 JSON 序列化/反序列化时，因为它具有类型注释，表明某些类必须实现 Serializable。通常像
StdDeserializer<T> extends JsonDeserializer<T> implements Serializable, Gettable
（我不认为 T 必须是可序列化的，只有序列化器？）
现在，我不明白为什么现在我们主要处理 JSON 和 XML 时，为什么还要处理二进制 Java 对象序列化的概念。为什么杰克逊（和其他“新”图书馆）会选择处理这个问题？
我唯一的猜测是，这与 Jakcson 的客户端序列化的域类无关，而是一些高级 JVM 用法可以在 JVM 之间传输使用中的各种对象或类似的东西，这将需要稳定的接口writeObject() 和 readObject()。但我在这里真的如履薄冰。
答案 0 :(得分：0)
在查看为 StdSerializer 类引入此问题的提交后，我与 Jackson 的维护者 Tatu Saloranta 就这个问题进行了联系，他详细回答了！在此处发布 his answer：
事实是这是一个用户请求，我记得，有 可能有 2 个用例，这可能有用。他们中的第二个可以 有点资格“在不同的 JVM 之间移动对象”。我有 同意这些用例似乎都不是特别 常见模式，fwtw。
第一个更奇特的（可能与也可能不相关） 这一点）是针对 Android 用例的解冻/解冻（或其他 当应用程序进入后台模式时调用它，返回，wrt XmlMapper (XML-backed ObjectMapper) -- 如果是这样，性能显然很高 与重新创建映射器相比，如果使用 JDK 序列化更好 实例。我不知道现在是否仍然如此。
第二，更广泛适用的用例将适用于像 Spark（或 Hadoop，可能是 Flink/Apache Beam），其中有一个协调器 节点可能想以某种方式配置映射器，然后将其发送到 初始化为特定设置的工作节点（还包括 注册模块，这就是序列化器/反序列化器的方式 相关的）。如果是这样，性能不是关键，而是能够准确地 要使用的配置。
但是试图使/保持（反）序列化器 JDK 可序列化是一个拖累和 这是我很高兴可以从 Jackson 3.x 中删除的东西（无论何时 被释放:))。 ObjectMappers 仍然是 JDK 可序列化的，但是 不需要许多/大多数内部组件。这个做完了 通过改变映射器的构建方式，我可能不应该 在这里深入细节。 :)