Support for Jackson 3?

[cunningt]

What are the plans for support of Jackson 3?

Jackson Jackson 3 migration requires changing the groupIds of the jackson artifacts and changing the package names of jackson packages from com.fasterxml.jackson.* -> tools.jackson and there are quite a few deprecations / API changes.

[catull]

Hey Tom What is your use case, why do need Jackson 3 ? Have you already done the upgrade? If so, send in a pull request? Regards, Catull

…

On Tue, Jan 13, 2026, 18:54 Tom Cunningham ***@***.***> wrote: *cunningt* created an issue (schibsted/jslt#380) <#380> What are the plans for support of Jackson 3? Jackson <https://github.com/FasterXML/jackson/blob/main/jackson3/MIGRATING_TO_JACKSON_3.md> Jackson 3 migration requires changing the groupIds of the jackson artifacts and changing the package names of jackson packages from com.fasterxml.jackson.* -> tools.jackson and there are quite a few deprecations / API changes. — Reply to this email directly, view it on GitHub <#380>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABEUJ5WCZ6J3ZJKXYSJ6HL4GUWMZAVCNFSM6AAAAACRSKF5B2VHI2DSMVQWIX3LMV43ASLTON2WKOZTHAYDSOJSGMZDANA> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[cunningt]

@catull Hi! I work on Apache Camel and am looking at Jackson 3 support there, and I'm trying to migrate the camel-jslt component but I think jslt needs to support Jackson 3 first (com.schibsted.spt.data.jslt.Expression.apply was what I saw as an issue)

I think both Jackson 2 and Jackson 3 might be able to live together on the same classpath, so I'm not sure how the jslt project wishes to approach this. I can definitely send a PR, but what would be preferable in that PR - support for both Jackson 2 and Jackson 3, or wholesale migration to Jackson 3?

[larsga]

Hi Tom. Thanks for asking, and thanks for the PR!

I've been thinking about this, and ideally we should support both Jackson2 and Jackson3, since there will probably be a transition period as projects move from Jackson2 to Jackson3.

The trouble is that the codebase is entirely tied to Jackson. So effectively we'll need to maintain one Jackson2 codebase and another for Jackson3.

One way to do this is to have two source trees in the same branch. Another is to have two branches. I haven't really decided what would be best.

(What would definitely be best would be to compile JSLT to bytecode (or Java code) to reduce the amount of code that needs to be duplicated. That way we could support GSON, too, and perhaps also have our own custom JSON implementation. That's not for now, though.)

[cunningt]

@larsga Circling back around - is there anything I can do to help? I know a month ago you weren't sure whether the right approach might be two branches or two source trees in the same branch, I'm happy to redo my PR around either.

[marcrohlfs]

Hi all!

Many thanks for the project and for the upgrade PR. We're also migrating to Jackson 3 and thus would be happy if this project supported Jackson 3. Spring Boot 4 and Spring 7 still support Jackson 2 next to Jackson 3 (we were lucky, original plans were to drop Jackson 2 support). But Jackson 2 integrations are deprecated and marked for removal, hence we'll be forced to migrate some day.

Supporting both Jackson versions in this project looks like a huge task. Wouldn't it be an option to bump the project to a new major version 1.0.x that supports only Jackson 3 and stick to Jackson 2 in 0.1.x? This should allow #381 to be merged near-term instead of having to reimplement. I could also offer some assistance here.

One more question: I'd be interested in how much alive this project actually is. The latest release has been published more than three years ago, and there were just a few PR merges or maintenance commits (like dependency updates) in the meantime - none of them released so far.

Best regards
Marc

[larsga]

Having thought about this a bit I think I agree with Marc that supporting both versions probably isn't something we want to do. It would be better to go with just one version, and it seems Jackson 3 would be the best, for obvious reasons.

I think the way to do that would probably be:

• Do a release of the current code, before merging the PR, so that there is a recent Jackson 2 version.
• Merge the PR, the release a Jackson 3 beta.
• Do all development on the main branch, but backport fixes to Jackson2 if necessary.

Any thoughts about this? I want to give people a chance to object or make alternative proposals before I make a change as momentous as this. If I don't hear anything I'll just do it this way.

[larsga]

I'd be interested in how much alive this project actually is

That's a good question. I'm not 100% certain myself. I find it difficult to devote much time to the project these days, but if people request fixes I'm happy to take care of those.

There are quite a few things I'd like to do with this project still, but it's hard to take time off from other things to get them done.

[sheshnath08]

There are quite a few things I'd like to do with this project still, but it's hard to take time off from other things to get them done.

Hi @larsga Could you please list some of the ideas here, I would be happy to make the contribution.

[larsga]

@sheshnath08 There are two main things I've been thinking of:

• Extend the language to make querying arrays easier.
• Compile to Java.

The second is important because it gives better performance and more flexibility. I've done it before, and got about 25% better performance. In theory we could also generate both Jackson 2 and Jackson 3 bytecode. In fact, we could even have our own JSON implementation and generate code for that, too.

At the moment the code does quite a bit of type checking, but if we compile to Java it would be possible to analyze the queries and determine the possible types of each sub-expression. In many cases it would then be possible to omit the type checking, thus improving performance. For example here:

let idparts = split(.id, "-")
let xxx = [for ($idparts) "x" * size(.)]

{
  "id" : join($xxx, "-"),
  "type" : "Anonymized-View",
  * : .
 }

We know at idparts is an array, so the for on the following line doesn't need to check that. The * operator knows it's working on a string, so we can pick that implementation of * right away. And so on.

[sheshnath08]

Hi @larsga — thanks for laying out your thinking on the compilation path. I'd love to contribute here and wanted to share a proposed approach before writing any code, to make sure it aligns with your vision.

Rather than tackling the full compiler in one go, I was thinking of breaking it into layers that can each be reviewed and merged independently:

Layer 1 — Type inference pass (standalone, no codegen)
Build a visitor that walks the existing AST and annotates each node with an inferred type (String, Number, Boolean, Array, Object, Null, Unknown). Using your example, split() would be annotated as always returning Array, which propagates to $idparts, allowing the for on the next line to be annotated as not needing an array check. This layer is self-contained, testable, and could also power better error messages down the line.

Layer 2 — Interpreter optimizations using type info
Feed the type annotations back into the existing interpreter to skip runtime type checks where the type is statically known. This should produce a measurable speedup without the complexity of a full compiler, and benchmarks would be the proof of value.

Layer 3 — Bytecode codegen for a subset of JSLT
Generate JVM bytecode (likely via ASM or ByteBuddy) for a well-defined common subset, falling back to the interpreter for anything outside it. From here, multi-target support (Jackson 3, a custom JSON representation) becomes a natural extension.

A few questions before I start:

• Is there an existing benchmark suite I can use to establish a baseline, or would that need to be created as part of this work?
• Do you have a preference on bytecode generation library (ASM, ByteBuddy, etc.), or is that open?
• What's the minimum Java version target I should design for?
• Any concerns about adding new dependencies for the codegen layer?

Happy to start with just a design doc / spike on Layer 1 if that's useful. Let me know what you think!

[cunningt]

It sounded like there was the possibility of a Jackson 3-supported beta - is that still possible? It sounds like there's a more elegant solution that would support both Jackson 2 and Jackson 3 that involves source or bytecode generation - what would be the timeline on that?

[cstmgl]

@larsga thanks for all the feedback considering the time that has pasted could we proceed with the feedback from @marcrohlfs and your suggestion?
Do the release of 0.1.x with the latest security fixes and then a new major release with the Jackson 3 support?

all your other points are important, definitely not an expert there, but if they are created as issues maybe people can then contribute there? and backport them to the 0.1.x release if they are relevant?