Why does Jackson implement Serializable?

Question

The built-in serialization of Java objects to their binary forms is not often seen in most projects these days, which tend to use ProtoBufs, XML, JSON, etc. for data transfer between servers. CORBA and all that seems to belong to projects of the 2000-ish era. To be honest, I have only seen it implemented once (in a J2EE project ten years ago) and it seems kind of quaint. I still get reminded of the whole Serializable thing every time IntelliJ complains about serialVersionUID is missing in some class, though! Nowadays, this mostly happens when I deal with JSON serialization/deserializtion using Jackson, as it has type annotations that says that some classes must implement Serializable. Typically stuff like

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

(I don't see that T is required to be serializable, only the serializer?)

Now, what I do not understand is why why are still dealing with this concept of binary java object serialization when we are mostly handling JSON and XML these days. Why would Jackson (and other "new" libraries) choose to deal with this?

My only guess is that this does not concern the domain classes that are serialized by the clients of Jakcson, but that some advanced JVM usage can transfer the various objects in use between JVMs or something like that, and that would require stable interfaces for writeObject() and readObject(). But I am really on thin ice here.

Answer 1

I was in contact with Tatu Saloranta, the maintainer of Jackson, about just this question after looking at the commit that introduced this for the StdSerializer class and he answered in detail! Publishing his answer here:

The truth is this came as a user request, and as I recall, there are maybe 2 use cases where this might be useful. Second of them could sort of qualify for "moving objects between different JVMs". I'd have to agree that neither of these use cases seems like particularly common pattern, fwtw.

First one that was bit more exotic (and may or may not be relevant at this point) was for Android use case for its thaw/unthaw (or whatever it is called when app goes into background mode, back, wrt XmlMapper (XML-backed ObjectMapper) -- if so, performance was apparently much better if using JDK serialization, compared to re-creating mapper instance. I don't know if that is still the case or not.

Second, more widely applicable use case would be for platforms like Spark (or Hadoop, perhaps Flink/Apache Beam), in which a coordinator node may want to configure mapper in some way, and then send it to worker nodes initialized to particular settings (including also registered modules, which is how serializers/deserializers would be relevant). If so, performance isn't the key but ability to have exact configuration to use.

But trying to make/keep (de)serializers JDK serializable is a drag and it is something I am happy I can drop from Jackson 3.x (whenever that gets released :) ). ObjectMappers are still JDK serializable, but without requiring many/most of internal components to be. This is done by changing the way mappers are constructed and I probably shouldn't go too deep into details here. :)