Invalid JavaType for "org.eclipse.persistence.indirection.IndirectList" class

[chkp-royl]

Describe the bug I need to upgrade Jackson package from version 2.5.0 to 2.11.3.

When deserialize JSON field from type "org.eclipse.persistence.indirection.IndirectList", the function constructSpecializedType in TypeFactory class returns invalid JavaType than in my current version (2.5.0).

Version information Which Jackson version(s) was this for? 2.11.3

Expected behavior Return same JavaType object like in version 2.5.0. The elements in IndirectList have custom deserializer and it's not being called at all. the logic in version 2.11.3 deserialize the elements as String object.

Additional context See _elementType diff. Should be simple type of CPUUID (which is my internal class) and not Object.

Version 2.5.0 Version 2.11.3

Thanks in advance, Roy

[cowtowncoder]

First things first: 2.11.3 is not the latest patch for 2.11 so the issue should have been tested against 2.11.4. But more importantly 2.11.x branch is not maintained so reproduction really is needed for something more recent: ideally 2.13.1, or alternatively 2.12.6

Description itself does not quite explain the problem so what I'd really need is a reproduction like unit test. Ideally without 3rd party types (instead copy-paste type definition in test), but if that is not possible, then including Maven dependency to test type.

But first it would be good to verify the issue exists in 2.13.1 or 2.12.6.

[chkp-royl]

Thanks for your quick respond. I tested both versions 2.13.1 and 2.12.6 and it doesn't work.

After some debugging I found out that issue happens from version 2.7.0. On version 2.6.7 it works good and I suspect the bug relate to issue #76 (type handling system)

I am working on unit test with no 3rd party dependencies. This is challenging because we have internal logic when de serializing objects from JSON to Java so I hope to share it with you ASAP.

Regards, Roy

[chkp-royl]

After more investigation I think I found the root cause of this bug. It's probably relate to serializing and not to deserializing like I thought at the beginning. See how my java object is serialized to JSON:

1. Version 2.5.0: ["objects.A",{"myList":["java.util.ArrayList",["some string"]]}]

2. Version 2.11.3: ["objects.A",{"myList":["java.util.ArrayList",[["objects.B","some string"]]]}]

For the given classes:

public class A
{
    private ArrayList<B> myList;
}

public class B
{
    private String text;
}

(class B serialized ONLY to text value)

The difference is the class path that added per object in "myList" member which not happen in version 2.5.0. When I try to deserialize objects using newer jackson version (after 2.6.7) that were serialized in version 2.5.0 this bug happen. Do you know if I should add logic that convert old serialize to new jackson version standards or something like that? How should I add this class path in version 2.5.0 so the serialization will be the same?

Regards, Roy

[cowtowncoder]

There is no way to try to configure the way Type Ids are written, except by annotations. Versions 2.5 and 2.6 are very very old by now, so I don't think anything in Jackson will help you handle the difference unfortunately.

Changes in such cases should only have occurred if the older version (2.5.x) had a bug in serialization code, and that was fixed in later version (2.6.x). Otherwise structure should not have changed.

Given this, I am not sure I can give much more help: if it was possible to have a test case where a new (2.12.6 f.ex) version wrote something that cannot be read with that version, we'd have a bug to work on. But unfortunately in this case it seems likely that a bug fix caused incompatibility. But with such an old version I don't really have time to dig any deeper.

[chkp-royl]

Ok, thanks for your help! What is the best practice in such case? Do I need to run same Jackson version when I do serialization & deserialization? Currently I do serialization in old version (2.5.0) and deserialization in new version (2.11.3 for example).

Regards, Roy

[cowtowncoder]

No, there should not be a requirement for versions to match; different minor versions should match.

But unfortunately in your case there seems to have been a change where this did not work.

As a general guidance I do think it is good idea to try to keep similar versions of Jackson across all your systems, migrating over time. But that should not be required for data / structure compatibility.

Another thing to consider is that some level of integration testing would allow verification of compatibility of new Jackson versions with your existing use cases: if issues are uncovered early enough (f.ex when new Jackson Release Candidates are released) they can be addressed to avoid compatibility issues.