[
https://issues.apache.org/jira/browse/SOLR-18325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18133265#comment-18133265
]
Nick Shanin commented on SOLR-18325:
------------------------------------
*Summary:* A SolrJ-only Jackson 3 prototype on the Solr 10 development branch
passes the tested Java 17 consumer and JSON compatibility checks. I propose
completing the client change first for 10.x, then assessing whether the server
and remaining modules can follow in 10.x. I can target Solr 11 instead if
preferred; the server migration has not yet been implemented or tested here.
[~epugh], following up on your question about consumer impact, I investigated a
client-first migration, leaving server-side code on Jackson 2.
The [test results and API
analysis|https://github.com/nick-boss-tech/solr/blob/23115b3c946bea6cf54155d7f666214741e1de13/reports/solr-18325-evidence-closeout-linux-round-1.md]
show:
* Maven and Gradle resolve the candidate without Jackson 2 core or databind on
the tested consumer's runtime path; the shared Jackson annotations remain.
* A consumer compiled with {{--release 17}} passes query/update/response
checks and HTTP operations against a released Solr 10.0.0 server.
* The 15 focused Jackson tests pass. Deliberately removing the compatibility
settings causes the expected failures for JSON defaults, depth/string limits
and exception wrapping.
* The public/protected API comparison against the pre-Jackson base finds the
{{JacksonContentWriter.DEFAULT_MAPPER}} type change and three additive helpers.
That class is already marked internal, but callers using its mapper field would
still need changes. The {{solr-api}} API is unchanged.
Released-binary compatibility remains unresolved: an application compiled
against SolrJ 10.0.0 fails at
{{HttpJdkSolrClient.Builder.withConnectionTimeout}} on both the unchanged
development base and the Jackson prototype. This traces to the earlier HTTP
hierarchy refactor in
[SOLR-17968|https://issues.apache.org/jira/browse/SOLR-17968] ([PR
3829|https://github.com/apache/solr/pull/3829]). I am investigating that
separately; these results do not establish a drop-in replacement for 10.0.0.
The experiment used Jackson *3.2.1*, not the ticket's requested *3.1.x*. The
selected version and a representative Spring Boot 4 application still need
verification. Full server/module migration is outside this prototype.
If a client-only change is acceptable independently, my recommendation is to
finish its remaining checks and submit it for review for 10.x. The expected
scope covers dependency declarations, {{JacksonContentWriter}},
{{JacksonDataBindResponseParser}}, response conversion, tests and small core
adjustments to keep server-side Jackson 2 independent. The server and remaining
modules would then need their own implementation and compatibility testing to
establish whether they can also target 10.x.
Is this evidence sufficient to pursue that staged approach for Solr 10, or
would you prefer a coordinated migration targeting Solr 11?
🤖 _AI text above_ 🤖 _(reviewed by Nick Shanin)_
> Upgrade Jackson from 2.x to 3.x (tools.jackson)
> ------------------------------------------------
>
> Key: SOLR-18325
> URL: https://issues.apache.org/jira/browse/SOLR-18325
> Project: Solr
> Issue Type: Improvement
> Components: SolrJ
> Affects Versions: 10.0
> Reporter: Bernd Wahlen
> Priority: Minor
>
> SolrJ (and Solr generally) depends on Jackson 2.x (com.fasterxml.jackson.*);
> solr-solrj:10.0.0 pulls jackson-databind:2.20. Jackson 3 is released, with
> 3.1 as the recommended stable line.
> Because Jackson 3 changed its Maven coordinates and packages
> (com.fasterxml.jackson.core/databind →
> tools.jackson.core/tools.jackson.databind), it can coexist with Jackson 2 on
> a classpath — but that's the problem downstream: applications that have moved
> to Jackson 3 (e.g. anything on Spring Boot 4, which now defaults to Jackson
> 3) and also use SolrJ are forced to ship both Jackson runtimes, since SolrJ
> keeps Jackson 2. Filing this to track the upgrade for a major release where
> the coordinate/package change is acceptable.
> Motivation
> - Align with the current Jackson line (3.1 stable); Jackson 2 will eventually
> EOL.
> - Let Jackson-3 downstreams avoid bundling two Jackson runtimes when they use
> SolrJ.
> Scope / considerations
> - Package/coordinate change across the codebase:
> com.fasterxml.jackson.{databind,core} → tools.jackson.{databind,core}.
> Annotations are unaffected — they stay com.fasterxml.jackson.annotation
> (Jackson 3 depends on jackson-annotations 2.20+ by design), so @JsonProperty
> etc. don't change.
> - API changes: ObjectMapper is immutable/builder-based
> (JsonMapper.builder()…build()); exceptions are unchecked now
> (tools.jackson.core.JacksonException replaces JsonProcessingException).
> - Jackson 3.0 is not LTS — target 3.1.x.
> - Needs alignment across all Solr modules (server, solrj, contribs).
> - Breaking coordinate change → natural fit for the next major (11.0, already
> in dev per SOLR-18003).
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
