Strategy around JUnit 6 and Jackson 3

[Guillaume Smet]

Hi,

Someone pushed a PR for JUnit 6 which is basically creating new artifacts that depend on the JUnit 5 Quarkus artifacts, which led me to reflect a bit on our strategy regarding JUnit and Jackson.

We could wait for Quarkus 4 next year but I wonder if it's not going to be very late, compared to when other frameworks adopted these libraries.

== JUnit 6

JUnit 6 breaks a few things but is not a revolution, meaning our stuff might work with JUnit 6. I will let Holly yell at me if that is not the case.

That being said, it apparently can break some user tests, most notably with the change in the CSV parsing library.

We cannot support both 5 and 6 so when we update, we might break some users but I wonder if we should just do it and hope for the best?

== Jackson 3

Here, it's a massive breaking change with new packages and new artifacts. I was wondering if we should create jackson3 artifacts for our Jackson support but that will require some additional work, typically we will need to fix issues in both extensions. And also we might need to duplicate some tests.

Also we might depend on libraries that are still using Jackson 2, which might be an issue. But then it's going to be an issue too if they start moving to Jackson 3.

If things work with just package renaming in these libraries, maybe we could apply the strategy we used for Jakarta and rewrite the bytecode. But... it might not work for some more advanced use cases. Or even the most basic ones: if they are creating their own formerly ObjectMapper, I think we are screwed.

However, we could have some support for Jackson 3 in Quarkus REST only for instance and wait longer for RESTEasy.

Now the big question is: does it have value apart from just showing we are not lagging?

Also both cases are extremely different so we might have different strategies for each.

In any case, whatever we decide, I think it's a decision we should communicate to our users as it might impact them.

Thoughts?

-- 

Guillaume

[Georgios Andrianakis]

Given how important Jackson is Vert.x, I don't believe doing something only on our side is the best move. When we do move, we should at least cover the most widely used parts of our stack.

As for JUnit 6, I say we just move straight to it if there are no serious issues

--
You received this message because you are subscribed to the Google Groups "Quarkus Development mailing list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to quarkus-dev...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/quarkus-dev/CALt0%2Bo-UZmdzJy0tj%3D5%2B7ppd_Bz6%3DuvVGVd8MeYEbkW_uqo5Fg%40mail.gmail.com.

[Eric Deandrea]

Spring Boot 4 uses both JUnit 6 & Jackson 3, so if we want to stay “competitive” I think we need to do this sooner than later.

Eric Deandrea

Java Champion

Senior Principal Software Engineer - Quarkus

Red Hat

edea...@redhat.com    M: 603.453.5840

--

[gegas...@gmail.com]

+1.

About JUnit 6, we have some artifacts named with `.*-junit5(.*)`  (eg. quarkus-junit5-internal), so I’d suggest relocating them to using `junit-jupiter` instead as a future-proof dependency  

To view this discussion visit https://groups.google.com/d/msgid/quarkus-dev/CALeTM-mNZrM8SWbD0T_UkxYAioNU1Wvc-aiu23n9RDvuHiTy8Q%40mail.gmail.com.

[Georgios Andrianakis]

I don't see why that would be the case, especially for Jackson where libraries might take a while to upgrade. 

Futhermore, having two instances of ObjectMapper is pretty detrimental to startup time and RSS.

To view this discussion visit https://groups.google.com/d/msgid/quarkus-dev/CAOTfCRU6F%2BMm%2Bak%3DYaZCAm7%3DqGYvH4OiEcB1PAg%2B3eF5GaP3Yg%40mail.gmail.com.

[Fouad Almalki]

+ TestContainers 2.0

To view this discussion visit https://groups.google.com/d/msgid/quarkus-dev/CALeTM-n8gGLxbns84wn0x7MN2pxA-%2BCuSCBAjWA16iSs3ZEH_w%40mail.gmail.com.

[Thomas SEGISMONT]

Hi,

Regarding Jackson 3, Julien has started to investigate: https://github.com/eclipse-vertx/vert.x/pull/5531

No major concern came out of this experiment.

Regarding JUnit6, our JUnit5 extensions works fine with it: https://vertx.io/blog/junit6-is-here/

But we haven't got any feedback from the community so far.

Regards,

Thomas

To view this discussion visit https://groups.google.com/d/msgid/quarkus-dev/CALeTM-mNZrM8SWbD0T_UkxYAioNU1Wvc-aiu23n9RDvuHiTy8Q%40mail.gmail.com.

[Eric Deandrea]

Spring Boot 4 uses Jackson 3 only (https://github.com/spring-projects/spring-boot/wiki/Spring-Boot-4.0-Migration-Guide#upgrading-jackson). You can bring in Jackson 2 if you wish, and then yes there would be 2 ObjectMappers.

But you’d have to opt into that by bringing in an additional dependency.

Eric Deandrea

Java Champion

Senior Principal Software Engineer - Quarkus

Red Hat

edea...@redhat.com    M: 603.453.5840

To view this discussion visit https://groups.google.com/d/msgid/quarkus-dev/CALeTM-n8gGLxbns84wn0x7MN2pxA-%2BCuSCBAjWA16iSs3ZEH_w%40mail.gmail.com.

[Georgios Andrianakis]

My point is that most dependencies that use Jackson will be on Jackson 2, so why should we be moving to Jackson 3 thus making our footprint worse for no measurable reason?

That's aside from the fact, that ideally we want at least Vert.x and Hibernate to be aligned with us when we choose to move

To view this discussion visit https://groups.google.com/d/msgid/quarkus-dev/CAOTfCRWVNht5m4hfZTwqztU4jgvgQNaRrZRUsmHOtozEytaN7A%40mail.gmail.com.

[Eric Deandrea]

I totally get your point from a technical perspective I think part of it isn’t a technical problem - its one of marketing.

Spring can boast out loud “We use & support Jackson 3, JUnit 6, Testcontainers 2 and Quarkus doesn’t”.

Just “one more time” Spring did something before we did.

Eric Deandrea

Java Champion

Senior Principal Software Engineer - Quarkus

Red Hat

edea...@redhat.com    M: 603.453.5840

To view this discussion visit https://groups.google.com/d/msgid/quarkus-dev/CALeTM-%3D%3DCfxT_xK3pXkPvFGusEpNQjChnxJB%3DHZZgVbccvZS_w%40mail.gmail.com.

[Georgios Andrianakis]

And if we do make the change, everyone can say, look, Quarkus 3.33 regressed by 20% in startup time and RSS 😉.

I'll revise my scores: -10 for Jackson 3 and +1 for JUnit 6 and TC 2

To view this discussion visit https://groups.google.com/d/msgid/quarkus-dev/CAOTfCRWYv6c%3DR6N%2BebgpivWN%2B96CtCGNhAucef5ceZ_AidxFjA%40mail.gmail.com.

[hantsy bai]

I would like to use the latest Jackson 3, JUnit 6, and Testcontainers 2, and rename the legacy module(jackson2, junit5) to a new module if possible. 

---

Regards,

Hantsy Bai

Self-employed consultant, fullstack developer, agile coach, freelancer/remote worker

GitHub: https://github.com/hantsy

Twitter: https://twitter.com/@hantsy

Medium: https://medium.com/@hantsy

To view this discussion visit https://groups.google.com/d/msgid/quarkus-dev/CALeTM-m9qVY6U0Mn7KnGgU-%3DonOiRQXHLjimHje3phLy8Tg-hA%40mail.gmail.com.

[hantsy bai]

Of course, like Spring Boot, Quarkus can also use a major version to align with the latest version of the new tech stack.

* Newer Java-based codes 

* Newer Jakarta EE standard

* Adopt all breaking changes in the newer libraries that align with the new specifications/standards

* Guidelines or OpenRewrite scripts to migrate to new major versions.

---

Regards,

Hantsy Bai

Self-employed consultant, fullstack developer, agile coach, freelancer/remote worker

GitHub: https://github.com/hantsy

Twitter: https://twitter.com/@hantsy

Medium: https://medium.com/@hantsy

[Claus Ibsen]

Hi

Would it be a good idea to keep as-is for now for the upcoming LTS in Q1 2026, so its a easy and smooth release for end users.

Also for Apache Camel as we keep staying on jackson 2, junit 5, and spring boot 3.x for our upcoming LTS release as well for Q1 2026.

Then after the LTS release then we gradually start to work on those big upgrades and see how we can balance this for both Quarkus and Spring Boot v4.

But in the short term the best value for our users is to make a release that are as-is.

[Domenico Briganti]

I think stepping up Jackson in Quarkus 4 make people to look more carefully at the Release Note, where they can see also the likely breaking changes the need to be fixed.
Jackson 3.0 doesn't bring new functionality so I prefer more stability over showing off that I'm using the last versions of the frameworks. I know, it's marketing, but reliability is a selling point, too.

Regards,

Domenico

Il 01/12/25 22:59, 'Georgios Andrianakis' via Quarkus Development mailing list ha scritto:

To view this discussion visit https://groups.google.com/d/msgid/quarkus-dev/CALeTM-m9qVY6U0Mn7KnGgU-%3DonOiRQXHLjimHje3phLy8Tg-hA%40mail.gmail.com.

[Guillaume Smet]

To clarify a bit:

- I haven't talked about Testcontainers 2 because I think we are not far from merging it - fingers crossed

- As for JUnit 6, it seems we want to have an open discussion about the strategy so I started: https://groups.google.com/g/quarkus-dev/c/yUc9s5U4DbA

- As for Jackson 3, I was somehow wondering if we could have a hybrid strategy of proposing some Jackson 3 support in select artifacts but I completely forgot Vert.x had a hard dependency on Jackson. It probably makes sense to wait a bit. What I'm a bit worried about is how we will be able to coordinate the whole upgrade across the stack and thus why I was considering a hybrid approach. Note that by hybrid I didn't mean people would have both but that they could choose Jackson 3 **if** the components they are using all support Jackson 3.

[Robert Stupp]

TC2 was a "no brainer" update for us. It's backwards compatible, if
people don't want or cannot change code. TC2 is IMO nicer, because
some "interesting" uses of Java generics disappeared ;)

I don't have a strong opinion on JUnit 6 itself, but it requires Java
17 as a baseline. We do have hard dependencies on some libraries that
have Java 11 as the baseline - including their test classes.
OTOH it's just "test code", so the worst thing would be to copy some
test classes. But there seem to be no (serious) breaking changes in
JUnit 6.
So I think JUnit 6 is fine.

Jackson 3 - I'd be careful, as it requires changing every code that
uses Jackson in some way. It's sad that Jackson 3 doesn't have a
backwards compatible layer to allow Jackson 2 code to run against a
"Jackson 3 runtime". There are tons of "new ObjectMapper()" out there
in many libraries :(
The "all or nothing" approach makes it quite tricky. APIs like
'io.quarkus.jackson.ObjectMapperCustomizer' would need to change.
I'm not sure how projects having a lot of dependencies could adopt
Jackson 3 (chicken-egg-problem?).

> --
> You received this message because you are subscribed to the Google Groups "Quarkus Development mailing list" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to quarkus-dev...@googlegroups.com.

> To view this discussion visit https://groups.google.com/d/msgid/quarkus-dev/CALt0%2Bo_zz1EjcFxrbKBW00TPEq6Nq4c78irOOx9xFK%3Dpfw9sHA%40mail.gmail.com.