Regression: `StackOverflowError` with recursive types that contain `Map.Entry`

[jloisel]

Hi,

I encounter the following issue with 2.6.x (works fine with 2.5.4):

java.lang.StackOverflowError
at com.fasterxml.jackson.databind.type.ClassKey.(ClassKey.java:43)
at com.fasterxml.jackson.databind.type.TypeFactory._fromClass(TypeFactory.java:869)
at com.fasterxml.jackson.databind.type.TypeFactory._constructType(TypeFactory.java:480)
at com.fasterxml.jackson.databind.type.TypeBindings._resolveBindings(TypeBindings.java:314)
at com.fasterxml.jackson.databind.type.TypeBindings._resolve(TypeBindings.java:212)
at com.fasterxml.jackson.databind.type.TypeBindings.findType(TypeBindings.java:126)
at com.fasterxml.jackson.databind.type.TypeFactory._fromVariable(TypeFactory.java:1068)
at com.fasterxml.jackson.databind.type.TypeFactory._constructType(TypeFactory.java:493)
at com.fasterxml.jackson.databind.type.TypeFactory.findTypeParameters(TypeFactory.java:397)
at com.fasterxml.jackson.databind.type.TypeFactory.findTypeParameters(TypeFactory.java:373)
at com.fasterxml.jackson.databind.type.TypeFactory._fromParamType(TypeFactory.java:1032)
at com.fasterxml.jackson.databind.type.TypeFactory._constructType(TypeFactory.java:484)
at com.fasterxml.jackson.databind.type.TypeBindings._resolveBindings(TypeBindings.java:267)
at com.fasterxml.jackson.databind.type.TypeBindings._resolveBindings(TypeBindings.java:328)
at com.fasterxml.jackson.databind.type.TypeBindings._resolve(TypeBindings.java:212)
at com.fasterxml.jackson.databind.type.TypeBindings.findType(TypeBindings.java:126)
at com.fasterxml.jackson.databind.type.TypeFactory._fromVariable(TypeFactory.java:1068)
...

The JUnit which shows how to reproduce the error:
https://gist.github.com/jloisel/1d36c017f5b27617c27b

[jloisel]

Maybe be better if we comment the issue here, not on the gist 👍

[cowtowncoder]

@jloisel haven't had time to dig into this yet. It does seem odd that there is discrepancy here.
I am guessing that it should be possible to further isolate the problem wrt datatype on common-lang (as per test project), but simply construct JavaType for it, instead of going through serialize or deserialize.
But I will try to find time to troubleshoot the problem as is; obviously there is something wrong going on.

[jloisel]

I'm going to try to isolate it further too. If i find something i'll let you know here.

[jloisel]

I isolated the bug a bit more:
https://gist.github.com/jloisel/c75ed016fd6607508ad7

It seems like it's related to the implemented interfaces which reference the type itself. I removed all external dependencies.

[cowtowncoder]

Thanks. There are known open issues wrt resolution of recursive type definitions (oldest open being #76 I think). What is odd is rather that this would surface between 2.5 and 2.6; not its existence.
Especially since support for Map.Entry itself was added in 2.5.

[cowtowncoder]

I think I know which change triggered the problem; TypeFactory actually proactively resolves Map.Entry type parameterization with 2.6. It should have been resolved by code anyway, at a later point, but probably either wasn't, or used slightly different code path.

I was also able to change code to work for the test case that resolves type; although now that I write this I realized I need to go back and verify that actual deserialization also works, just to be sure.