I’m working with Java object serialization and deserialization. In my serialized JSON, I include the @class attribute to store the fully qualified class name, like this:

{
    "@class": "com.a.b.c.d.dto.Dto123",
    "id": 1,
    "name: "john"
}

My understanding is that this @class information helps during deserialization to correctly reconstruct the object into the proper class type.

However, I noticed something strange: even when the class path specified in @class has changed, for example from com.a.b.c.d.dto.Dto123 to com.a.b.c.d.dto.d.Dto123, the deserialization process still succeeds without errors. I expected it to fail since the original path no longer exists.

Why does deserialization succeed even when the @class path has changed? Is there some mechanism in Java or certain frameworks that allows this to happen? Could it be related to how the classloader works, or are there fallback mechanisms in place that I’m not aware of?

Any insights or explanations would be greatly appreciated!

What did you try?

• I set up two instances of the server running on different ports, both sharing the same Redis cache. I serialized the object using one server (with the older class path) and tried deserializing it using the other server (with the new class path). (success)

What were you expecting?

• I expected that when deserializing the object on the server with the new class path, it would fail or throw an error because the @class path in the serialized JSON doesn’t match the new class path. However, the deserialization process succeeds without any issues, which is confusing. I’m trying to understand why this happens.