spring-projects
Investigate Upgrade to Jackson 3
https://github.com/FasterXML/jackson/wiki/Jackson-Release-3.0
Related to: spring-projects/spring-data-commons#3292 Due to the amount of breaking changes the upgrade will have a broader impact.
Did a first step (have a branch in my fork):
I had to change the dependencies and imports. Some adjustments where methods that have been renamed (or better the old ones had been deprecated). So far this works, BUT:
I hand a customized ObjectMapper into the JacksonJsonpMapper that is passed into the RestClient from Elasticsearch (the one ES uses by default discards null values, but sending null values to ES is a valid use case). And the JacksonJsonpMapper of course expect a com.fasterxml.jackson.databind.ObjectMapper.
I will need some more investigation how to address that.
Looking at https://central.sonatype.com/artifact/co.elastic.clients/elasticsearch-java, the Elasticsearch client 9 references Jackson 2.18.3.
ok, as Jackson changed the coordinates and package names, it is possible to use a version 2 ObjectMapper for the Elasticsearch client and version 3 for Spring Data Elasticsearch.
Not sure if this is a good idea, and what consequences this might have for users.
For the time being, we support Jackson 2 side by side with Jackson 3 where possible (e.g. by introducing a Jackson 3-based converter/reader variant) favoring Jackson 3 over Jackson 2 where applicable.
I assume that we will have to support this arrangement until the broader ecosystem has fully migrated to Jackson 3.
Looking at MapDocument, DefaultStringObjectMap, and MappingBuilder I wonder whether we could remove ObjectMapper use from these types at all. toJson() seems a convenience method that is only used in a few specific places (TypeMapper, TypeUtils, RequestConverter).
Would it be possible to switch over to JsonProvider or JsonpMapper JSON processing? In some places (withJson) it seems that we rather use JSON as way to provide settings and let the builders call the methods to bring values into a builder.
Removing the ObjectMapper from Spring Data Elasticsearch code would definitely mean some bigger rewrite. The MappingBuilder heavily passes the ObjectNodes from that around.
We need mapping from JSON strings to data, both for our users passing in settings, mapping and configuration and for some of the responses.
But how would that change change the fact that we have a dependency to Jackson 2 through Elasticsearch? We need to pass a JsonpMapper into the creation of an ElasticsearchClient, they provide the JacksonJsonpMapper which we currently use and a JsonbJsonpMapper which according to Elasticsearch's code documentation is not efficient as the do some "string representation roundtrips" there.
The Jackson 3 migration will likely last for a couple of years and probably. I expect that only CVEs and eventually not maintained Jackson 2 will incentivize (or force) the wider ecosystem to migrate to Jackson 3. I don’t want to remove Jackson as dependency, quite the contrary.
Looking through the code, we have quite a few ObjectMapper instances and some areas seem to make use of Jackson more because it is there than because it is necessary. I don’t have the full picture, but that was my impression. I understand that certain functionality has to be JSON and that’s totally fine.
My remarks are more about the design of the aforementioned spots that could benefit from some refinements and to contain the Jackson sprawl (if that makes sense). Am 27. Sept. 2025, 19:30 +0200 schrieb Peter-Josef Meisch @.***>:
sothawo left a comment (spring-projects/spring-data-elasticsearch#3113) Removing the ObjectMapper from Spring Data Elasticsearch code would definitely mean some bigger rewrite. The MappingBuilder heavily passes the ObjectNodes from that around. We need mapping from JSON strings to data, both for our users passing in settings, mapping and configuration and for some of the responses. But how would that change change the fact that we have a dependency to Jackson 2 through Elasticsearch? We need to pass a JsonpMapper into the creation of an ElasticsearchClient, they provide the JacksonJsonpMapper which we currently use and a JsonbJsonpMapper which according to Elasticsearch's code documentation is not efficient as the do some "string representation roundtrips" there. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: @.***>
I see that Jackson is starting his upgrade guide.
https://github.com/FasterXML/jackson/blob/main/jackson3/MIGRATING_TO_JACKSON_3.md
There is no problem in migrating Spring Data Elasticsearch to Jackson 3, I have that in a branch. But we still have the dependency through elasticsearch-java, which needs Jackson 2.
we still have the dependency through elasticsearch-java, which needs Jackson 2.
elasticsearch-java-client 9.2.0 added support for Jackson 3.
I upgraded my branch, the current code now is all switched to Jackson3.
I still need to keep Jackson2 as optional runtime dependency, as we only deprecate the use of the Elasticsearch RestClient and do not yet remove it.
Still need to do some tests in my sample test application and adjust some documentation, otherwise this would then be ready to go.
@sothawo shouldn't this change also need to backport to 6.0 line to avoid Jackson 2 altogether?
First, we cannot yet avoid Jackson 2 altogether at the moment, it is still an optional dependency because users might still use the old RestClient as this is deprecated will be removed later.
Second, this did not make it in the 6.0 branch in time, as it would have needed to have been merged before the release of the last 6.0.0-RC version. We do not add changes between the last RC and GA, only bugfixes. And as for backporting, we only backport bugfixes into released branches.