Migration to Jakarta EE packages (javax.* to jakarta.* namespace change)

[michael-schnell]

Description

Other frameworks like Spring announced their movement to Jakarta EE 9+ with "javax." to "jakarta." namespace change. Quarkus should also support this.

At least a roadmap would be nice:
https://stackoverflow.com/questions/69438312/roadmap-for-quarkus-jakarta-ee-9-javax-to-jakarta-namespace-change

Subtasks

• Quarkus 3.0 code migration update facility #23842
• Maven auto-transform Jakarta extension  #23847
• EE10 is released
• MP/SR has a compatible EE10 update or perhaps draft

Components (non-exhaustive)

• Hibernate produces a Jakarta artifact
• Resteasy Reactive Jakarta conversion (issue TBD)

[gsmet]

This is on our radar but we do not have a concrete plan for it yet.

[michael-schnell]

Would be great if the JEE/Quarkus community is not slower with this important topic than the competitor Spring Boot ;-)

[michael-schnell]

In the meantime SpringBoot already got a running snapshot while the "JEE native" Quarkus has not even a timeline:
https://twitter.com/juliendubois/status/1466333852021018627

[arjantijms]

@gsmet

This is on our radar but we do not have a concrete plan for it yet.

It's now a month later, do you already have a plan for it by now?

[gsmet]

Our current position is that Jakarta EE 9 has a high impact on the users while not bringing much to the plate feature-wise.

We have plans to work on Jakarta EE 10 integration once it's available and also try to reduce the potential impact on the users.

[arjantijms]

while not bringing much to the plate feature-wise.

It's actually not bringing anything at all feature-wise. That's by design.

We did a Jakarta EE 9 so that tool and library vendors (such as yourself) and your users can more gradually prepare. I thought that was actually the strategy Red Hat had as input when we decided this and voted for it.

[michael-schnell]

We did a Jakarta EE 9 so that tool and library vendors (such as yourself) and your users can more gradually prepare.

Mixing new features with the name space change seems not to be a good idea. I guess that's exactly why the Readhat strategy was: "EE 9 = namespace change" / "EE 10 = new features".

[gpor0]

Any updates on this, some people are having issues using Quarkus along with new versions of libraries already having jakarta.validation dependencies. As a result we are in dependency conflict state and therefore stuck with the old versions since Quarkus does not provide a way to switch to new version. I know the pain and this should handled differently by Jakarta, but is it possible to make some kind of workaround like having quarkus-hibernate-validator-jakarta or something?

[gsmet]

@gpor0 which libraries?

[gpor0]

One of the examples in my case is Jooq but I believe many projects will start upgrading to newer versions of Jakarta soon...

[gsmet]

Well, the newer versions of Jakarta are not yet ready. But sure, that's gonna happen.

And we will move to them. We just haven't agreed on a schedule yet.

Anyway, it's a good thing to list things that start to become problematic here.

[lukaseder]

One of the examples in my case is Jooq but I believe many projects will start upgrading to newer versions of Jakarta soon...

For the record, jOOQ 3.16's upgrade was mostly driven by this: spring-projects/spring-boot#28821 (Spring again).

[arjantijms]

@lukaseder thanks for moving though. It's a painful process (I've been involved with the move to jakarta.* since the very start), but the more projects move over the sooner it's done. The latest versions of Tomcat and Jetty have moved as well, so more and more people will be asking for Jakarta.* versions.

[arjantijms]

@gsmet

We just haven't agreed on a schedule yet.

It should be really much later than when CDI-Quarkus is released right? As that one is using the Jakarta.* namespace.

[lukaseder]

@arjantijms Yes indeed. jOOQ doesn't make a lot of use of Jakarta packages, it's just a tiny integration layer, and nonetheless, this issue got 6 upvotes: jOOQ/jOOQ#9641. I think it's time.

[n1hility]

I hope you don't mind I repurposed this to a main tracking EPIC.

[gsmet]

For the record, we have started a Jakarta initiative with a first goal of automating entirely the migration to Jakarta EE 9 using the Eclipse Transformer and OpenRewrite and make it reproducible.

Once this is done we will work on updating to EE 10 (it will require some code changes so we want to do that in a second step). Again with the goal of automating the whole update.

If you are interested in this effort, we are labelling every PR of this initiative with the area/jakarta label:
https://github.com/quarkusio/quarkus/pulls?q=is%3Apr+label%3Aarea%2Fjakarta

The core of the infrastructure is almost done. Then we will have to go through the extensions to tweak them individually. For most of them, it shouldn't require too much work but some specific ones will require some more involved work.

I'll post here about our progress from time to time.

[mshabarov]

@gsmet could you please give an estimated date when you plan to release a prerelease/GA version of Quarkus with Jakarta EE 9 or 10 support? Based on this board, the work seems to be in progress https://github.com/orgs/quarkusio/projects/13/views/20.

[gsmet]

@mshabarov I'm preparing a blog post to explain our plans.

[arimeyer]

We're also looking forward to using JPA 3 and Hibernate 6.x, which are dependent on the Jakarta EE migration. I posted about this a few months back: #26766 . Thanks

[geoand]

Quarkus main has already moved to jakarta packages and the Alpha* releases provide a way for users to test what will soon be Quarkus 3