Double array serialization of LocalDate stored as an object with wrapper object typing enabled

[unintended]

version: 2.9.2

For some reason localdate is serialized as double array

public class ObjectMapperTest {

    private ObjectMapper objectMapper;

    @Before
    public void setUp() throws Exception {
        StdTypeResolverBuilder typeResolverBuilder =
                new ObjectMapper.DefaultTypeResolverBuilder(ObjectMapper.DefaultTyping.NON_FINAL)
                        .init(JsonTypeInfo.Id.CLASS, null)
                        .inclusion(JsonTypeInfo.As.WRAPPER_OBJECT);

        objectMapper = new ObjectMapper();
        objectMapper.setDefaultTyping(typeResolverBuilder);
        objectMapper.findAndRegisterModules();
    }

    @Test
    public void testLocalDateSerialization() throws JsonProcessingException {
        final LocalDate localDate = LocalDate.of(2017, 12, 5);
        String dateHolderStr = objectMapper.writeValueAsString(new Holder(localDate, localDate));
        Assert.assertEquals("{\"localDate\":[2017,12,5],\"object\":{\"java.time.LocalDate\":[2017,12,5]}}", dateHolderStr);
    }

    @JsonTypeInfo(use = JsonTypeInfo.Id.NONE)
    private static class Holder {
        @JsonProperty
        private LocalDate localDate;
        @JsonProperty
        private Object object;
        public Holder(LocalDate localDate, Object object) {
            this.localDate = localDate;
            this.object = object;
        }
    }
}

Expected :{"localDate":[2017,12,5],"object":{"java.time.LocalDate":[2017,12,5]}}
Actual   :{"localDate":[2017,12,5],"object":{"java.time.LocalDate":[[2017,12,5]]}}

[cowtowncoder]

Yes, that seems wrong.

[cowtowncoder]

Unfortunately I can not reproduce this against 2.9.2. But I vaguely remember something like this, which was due to refactoring of type id handling in 2.9. So one thing to check is to make 100% sure that dependencies for jackson-core (especially) and jackson-databind are 2.9.2 and not, say, 2.9.0.
(jackson-annotations is fine to be 2.9.0 -- this jar never changes in patches).

[unintended]

I made a test project for it https://github.com/unintended/localdatetest
All the dependencies are 2.9.2, but it still fails:

$ mvn dependency:tree
[INFO] Scanning for projects...
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Building localdate-test 1.0-SNAPSHOT
[INFO] ------------------------------------------------------------------------
[INFO]
[INFO] --- maven-dependency-plugin:2.8:tree (default-cli) @ localdate-test ---
[INFO] com.jackson.test:localdate-test:jar:1.0-SNAPSHOT
[INFO] +- com.fasterxml.jackson.core:jackson-core:jar:2.9.2:compile
[INFO] +- com.fasterxml.jackson.core:jackson-annotations:jar:2.9.2:compile
[INFO] +- com.fasterxml.jackson.datatype:jackson-datatype-jsr310:jar:2.9.2:compile
[INFO] |  \- com.fasterxml.jackson.core:jackson-databind:jar:2.9.2:compile
[INFO] +- com.fasterxml.jackson.module:jackson-module-parameter-names:jar:2.9.2:compile
[INFO] +- com.fasterxml.jackson.datatype:jackson-datatype-jdk8:jar:2.9.2:compile
[INFO] \- junit:junit:jar:4.12:test
[INFO]    \- org.hamcrest:hamcrest-core:jar:1.3:test
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 0.990 s
[INFO] Finished at: 2017-12-07T11:59:41+03:00
[INFO] Final Memory: 14M/309M
[INFO] ------------------------------------------------------------------------

The strange thing is that in console log it's logged as double and triple brackets:

testLocalDateSerialization(com.jackson.test.ObjectMapperTest)  Time elapsed: 0.299 sec  <<< FAILURE!
org.junit.ComparisonFailure: expected:<...va.time.LocalDate":[[2017,12,5]]}}> but was:<...va.time.LocalDate":[[[2017,12,5]]]}}>

In IDEA still:

org.junit.ComparisonFailure: 
Expected :{"localDate":[2017,12,5],"object":{"java.time.LocalDate":[2017,12,5]}}
Actual   :{"localDate":[2017,12,5],"object":{"java.time.LocalDate":[[2017,12,5]]}}

[unintended]

2.8.10 works well btw

[cowtowncoder]

Hmmh. Well that is odd. Will try to see if I can reproduce it locally then.
As I said, problem itself does sound familiar, I just do not remember where. Another thing that is different is inclusion of parameter names module, but I don't think that should matter here.

[unintended]

It’s just a copy-paste from my main project, so I forgot to remove parameter module from dependencies, but during experiments I tried to remove it, and it didn’t make any difference.

[cowtowncoder]

Oh lol. My test failed to fail because it wasn't being run. Once that is resolved it fails as expected.
And I think I can see why now; it is not overriding default polymorphic type handling from base implementation, which assumers scalar representation.