6

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.

oligofren
  • 20,744
  • 16
  • 93
  • 180
  • your problem is with intellij, not with java. there is no need to actually define a serialversionid. if you don't use built in serialization, you should just disable the inspection in intellij – Andi Mar 11 '21 at 12:06
  • That was not my question, though. I was asking about Jackson, even though IntelliJ might complain :) It was more that I just get reminded that this interface exists still at all. – oligofren Mar 11 '21 at 12:07
  • This is very hard to answer, because only the developer of this exact `class` may give insight on the *why* they did it. – Lino Mar 11 '21 at 12:11
  • @Lino How could I rephrase this question to make it more useful? I am not interested in Jacson per se, but more of a discussion on why modern libraries would even bother to deal with that stuff. – oligofren Mar 11 '21 at 12:36
  • 1
    For a long time, the standard advice was basically to make everything serializable if it can be easily done. Nowadays, things look different, see [this related question](https://stackoverflow.com/questions/4548816/when-should-we-implement-serializable-interface). However, as a library provider, you need to consider if making your classes serializable is something you want to support. Being able to save the state of a serializer may not seem a super-common usecase, but it was probably easy to implement. Seems the creators considerered it worthwile. – Hulk Mar 11 '21 at 12:42
  • 1
    Judging by the [JavaDocs of StdDeserializer](https://fasterxml.github.io/jackson-databind/javadoc/2.1/com/fasterxml/jackson/databind/deser/std/StdDeserializer.html), `Serializable` was not present in 2.0 but was there in 2.1. You could probably dig up the change request that led to adding it. – Hulk Mar 11 '21 at 12:45
  • So this probably happened around 2012. Also note that removing such an interface would be a breaking change. – Hulk Mar 11 '21 at 12:53
  • This [issue](https://github.com/FasterXML/jackson-databind/issues/103) may account for the reason. – samabcde Mar 11 '21 at 13:33

1 Answers1

4

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. :)

oligofren
  • 20,744
  • 16
  • 93
  • 180