Serialization problem with type specialization of nested generic types

[dnno]

We're facing a problem in our project when updating to the latest Spring Boot version (1.5.12) which upgrades from Jackson 1.8.10 to 1.8.11: Serialization of some of our classes now doesn't work anymore. Going up to 1.9.5 the same problem still persists for us.

I was able to track this back to a change in issue #1604 where I've commented earlier. I'm opening a new issue as suggested there, but this problem could be connected to #1964.

I've isolated our problem into a simple maven based project, you can find it here:

https://github.com/dnno/jackson-serialization-problem/

The classes we try to serialize make use of generics and Jackson now isn't able to handle them anymore. Type resolution stops here:

TypeFactory._verifyAndResolvePlaceholders():476

if (exp.getRawClass() != act.getRawClass()) {
return false;
}

I don't really understand a lot of what's happening here, but what I do see is, that if I manually set the resulting error String to , the serialization will work fine.

Could it be, that it's wrong to just compare for the same raw classes, but instead traverse the type hierarchy? In my case it's comparing a List (actual) to an Object (expected). A successful comparison would make sense for me.

[cowtowncoder]

From description I suspect this might well be same as #1964, or related.

If so, it is plausible that your generic type declarations are incorrect, and newer versions find the assignment incompatibility. If so, while unfortunate that earlier versions allowed this, it would probably make sense to try to see where the type assignments are incorrect and fix those.

As to comparison for subtypes, if I understand situation correctly, Java compiler itself would not allow such assignment.

[cowtowncoder]

Ok I can reproduce the issue.

I was hoping this could be another relatively small work-around (as with #1964), but this is definitely nothing as simple. I will have to think about this a bit as I am not quite sure how type co-variance really should work (as in: what substitutions would be non-dangerous, at least, even if not type-assignable).

[cowtowncoder]

I found a way to resolve this particular issue, by allowing refinement from Object up without further checks. I think that should be reasonable, to avoid challenges with "raw" types, although I suspect there's a chance this could sometimes hide problems. But I think it is reasonable change for now, given that this usage has worked before.

Fix will be in 2.9.6 which should be out relatively soon.

[dnno]

Thanks for looking into this and resolving this problem! Looking forward to the new version!