Jackson 3 migration guide for BasicPolymorphicTypeValidator

[brainbaking]

Hi all,

We are working towards making our async background job processor library compatible with Jackson 3 (see jobrunr/jobrunr#1415) and encountered more than a few problems-no wait, challenges-during the process.

The biggest problem we had is the lack of proper documentation: the migration guide did not cover our specific quirks. For example, we relied on LaissezFaireSubTypeValidator that suddenly became inaccessible (not covered in the guide) so I had to learn how to use the BasicPolymorphicTypeValidator.builder() (also not there?)

Do you folks accept a PR to help improve said guide?
Thanks!

Cheers,
Wouter

[pjfanning]

PRs for https://github.com/FasterXML/jackson/blob/main/jackson3/MIGRATING_TO_JACKSON_3.md are much appreciated

[brainbaking]

Super! I took a stab, feedback welcome #317

[cowtowncoder]

Thank you @wgroeneveld -- these were indeed gaps in the migration guide. And probably something many users will encounter, so you are saving everyone a lots of time and effort.

[lukaszungier]

@cowtowncoder, @brainbaking — FYI, I ran into issues with serialization/deserialization when using Jackson 3 for caching purposes.

Even after following the guidelines from section "ObjectMapper: automatic inclusion of type information configuration", I was not able to get it working correctly for List and Set return types.

It seems that type information is not preserved properly, which makes deserialization fail (or produce incorrect results) for generic collection types.

Minimal example:

ObjectMapper mapper = JsonMapper.builder()
    .activateDefaultTyping(...)
    .build();

List<Foo> input = List.of(new Foo("bar"));

String json = mapper.writeValueAsString(input);

// expected: type info included
// actual: missing or insufficient type info

List<Foo> result = mapper.readValue(json, List.class); // fails or loses type info

As a workaround, I ended up wrapping collections into dedicated single-field records:

public record FooList(List<Foo> values) {}

This works correctly with Jackson 3:

FooList wrapper = new FooList(List.of(new Foo("bar")));

String json = mapper.writeValueAsString(wrapper);
FooList result = mapper.readValue(json, FooList.class);

Is there something missing in the documentation regarding this use case,
or is this a known limitation? Or am I just making confusion here?

Happy to provide more details if needed.

[JooHyukKim]

the problem is Java type erasure. You can try to use type reference.

[lukaszungier]

Thanks for answer @JooHyukKim
I pasted here some code example to visualise flow.
However, in production I run into these issues while using Spring Boot's @Cacheable mechanisms, which were working before upgrade.

[JooHyukKim]

Could you check how @Cacheable is implemented by Spring team or how your application configured mapper?
Jackson-only reproduction would quite help.
No need for full-blown repositories or zip files. Just like how other issue are writeen (see jackson-databind repo for examples)

[cowtowncoder]

@lukaszungier please do not add issue reports on random discussions. File an issue on jackson-databind.
And yes, reproduction needs to be stand-alone without Spring Boot dependency.

@JooHyukKim I suspect this is not about caching.

[lukaszungier]

Thanks @cowtowncoder, I'll prepare example and create new issue.
It seemed natural to comment here, as I also migrated from LaissezFaireSubTypeValidator to BasicPolymorphicTypeValidator usage, which was part of documentation extension here.