Problem deserialization "raw generic" fields (like `Map`) in 2.11.2

[cowtowncoder]

(note: follow-up to #2821)

Looks like there are some problems with passing of type resolution context in case of "raw" references to generic types, something like:

class Generic<T> {
   public Map value;
}

where in resolution is attempted for raw Map (expressed as Class<?> and not GenericType); type resolver gets confused.
Full reproduction provided in #2821 by @MartinTeeVarga is as follows:

    static class GenericEntity<T> {
        T field;

        Map map;

        public void setField(T field) {
            this.field = field;
        }

        public T getField() {
            return field;
        }

        public Map getMap() {
            return map;
        }

        public void setMap(Map map) {
            this.map = map;
        }
    }

    static class SimpleEntity {
        Integer number;

        public void setNumber(Integer number) {
            this.number = number;
        }

        public Integer getNumber() {
            return number;
        }
    }

    public void testTypeRefinementIssue() throws Exception {
        ObjectMapper m = new ObjectMapper();
        final String JSON = "{ \"field\": { \"number\": 1 }, \"map\": { \"key\": \"value\" } }";
        GenericEntity<SimpleEntity> genericEntity = m.readValue(JSON,
                new TypeReference<GenericEntity<SimpleEntity>>() {});
        assertNotNull(genericEntity);
    }

[cowtowncoder]

Ok yes. I think that the original changes for #2796 were the root cause here. Fundamentally I think TypeBindings abstraction is confusing and used in incorrect way here; and as as @lhotari suggested the fix for 2.11(.3) needs to be to apply bit of filtering by callers.
For 2.12 I will try to change TypeFactory API slightly to probably deprecated public JavaType constructType(Type type, TypeBindings bindings), suggesting users not use, and change internal code to call a new similar method but one that knows to NOT apply bindings to Class<?>.

Anyway, I think this might be complete fix for 2.11.3; I wish we had more unit tests for raw generic types as this would have been caught earlier.

[MartinTeeVarga]

Thanks for this. I am using Jackson in an app using Kotlin, GraphQL Java and Spring Boot - I wasn't able to isolate the problem yet. I will try the next version containing this fix and if it doesn't fix my issue, I will investigate further.

[cowtowncoder]

@MartinTeeVarga thank you for your help here! As I said I wish I had avoided this self-inflicted regression but I think it should be properly resolved now for 2.11.3 (and 2.12.0).