javax to jakarta
javax to jakarta migration: the rename, the stragglers and the recipe.
Changing the imports is the easy part. Finding every library, descriptor and string that still says javax is the work.
The short answer
The javax to jakarta migration renames Java EE packages from javax.* to jakarta.* because Java EE moved to the Eclipse Foundation as Jakarta EE. Jakarta EE 9 made the rename, and Spring Boot 3 and Tomcat 10 require it. Imports are rewritten by a recipe. Libraries, descriptors and reflective strings need review.
Background
Why did javax become jakarta?
Oracle transferred Java EE to the Eclipse Foundation but kept the rights to the javax name. The new platform, Jakarta EE, therefore had to use a new package prefix. Jakarta EE 9 renamed the packages and changed no features. Jakarta EE 10 and later add features on top of the new names.
The rename matters now because current runtimes depend on it: Spring Boot 3 (Spring Framework 6), Tomcat 10 and later, Jetty 11 and later, and current Hibernate and Jersey releases. You cannot mix the two sets in one classpath for the same API.
Scope
Which packages change, and which stay javax?
Only Java EE packages move. Packages that belong to the JDK or to Java SE keep javax. A blind find and replace breaks these.
| Moves to jakarta | Stays javax |
|---|---|
| javax.servlet, javax.servlet.http | javax.sql (JDBC) |
| javax.persistence (JPA) | javax.naming (JNDI) |
| javax.validation | javax.crypto, javax.net, javax.net.ssl |
| javax.ws.rs (JAX-RS) | javax.security.auth, javax.security.cert |
| javax.annotation (@PostConstruct and others) | javax.management (JMX) |
| javax.inject, javax.enterprise (CDI) | javax.xml.parsers, javax.xml.transform |
| javax.jms, javax.ejb, javax.transaction | javax.swing, javax.imageio |
| javax.xml.bind (JAXB), javax.xml.ws (JAX-WS) | None of the above |
Tooling
What does the OpenRewrite jakarta recipe do?
The OpenRewrite javax to jakarta recipe, usually org.openrewrite.java.migrate.jakarta.JavaxMigrationToJakarta, rewrites imports and fully qualified names, updates XML descriptors such as web.xml and persistence.xml, and bumps known dependencies to their jakarta versions. Confirm the name against the current catalogue before use. See OpenRewrite for how recipes work and what they leave undone.
Other tools exist. The Eclipse Transformer rewrites compiled classes and jars, which helps when you cannot change source. Apache Tomcat provides a migration tool that converts web applications for Tomcat 10. We use a recipe on source, since the result is a diff an engineer can read.
The hard part
Which libraries lag, and how do you find them?
A dependency that still ships javax classes fails at runtime, often with a ClassNotFoundException or a NoSuchMethodError deep in a stack trace. For every dependency that touches servlets, persistence, validation, REST, JAXB, mail or JMS, check for a release built on jakarta.
- Hibernate: version 6 for jakarta. Version 5.6 offers a jakarta classifier as a bridge.
- Jersey: version 3 and later. CXF: 3.5 and later for jakarta.
- Jackson: the JAX-RS and JAXB providers have jakarta variants. Check each module you use.
- Swagger and OpenAPI libraries: use jakarta builds, or move to springdoc for Spring.
- Unmaintained libraries: some have no jakarta release at all. Replace them or fork.
- Application-specific vendor libraries: ask the vendor, because this is the item that sets the schedule.
Hidden references
What else still says javax after the recipe?
These are the ones that pass compilation and fail in production. A search for the string javax outside imports, plus a full test run, finds most of them.
- String class names in XML or properties files, for example a filter class or a JPA provider name.
- META-INF/services files and Spring factories that list javax implementations.
- Reflection and Class.forName calls built from strings.
- XML namespaces in descriptors, which must point to the jakarta schemas.
- Generated sources, for instance JAXB or JAX-WS output checked into the repo.
- Build plugins and annotation processors that generate javax code.
Sequence
What order should the migration run in?
For the framework side of the same change, see Spring Boot 3 migration. For the server side, see WebLogic to Tomcat.
- 2
Dependency audit
List every library and its jakarta status before touching code.
- 3
Run the recipe
Apply it, then read the diff and the compile errors.
- 4
Fix stragglers
Upgrade, replace or shim each library. Check the hidden references above.
- 5
Test
Run the suite against a jakarta runtime such as Tomcat 10.1 or a Jakarta EE 10 server.
Evidence
What does a recipe run find on a real application?
We are running the recipe on an open-source Java 8, Spring Boot 2 application. The run will report files changed, the unresolved-dependency list and test results before and after. It is not published, so we state no numbers. This is the first-party data the page will carry when it is ready.
It is the rename of Java EE packages from javax.* to jakarta.*, required by Jakarta EE 9 and later, Spring Boot 3 and Tomcat 10 and later.
Oracle moved Java EE to the Eclipse Foundation but kept the javax trademark, so the platform had to use a new prefix. Jakarta EE 9 made the rename with no feature changes.
Java SE and JDK packages stay, such as javax.sql, javax.naming, javax.crypto, javax.net and javax.management.
Yes. The OpenRewrite jakarta recipe rewrites source, and the Eclipse Transformer works on compiled jars. Both leave dependency and configuration review to you.
Only when you move to a runtime that requires it, such as Spring Boot 3 or Tomcat 10 and later. Staying on javax means staying on older versions that stop receiving updates.
Not for the same API in one classpath. A javax library calling a jakarta runtime will fail. Convert or replace the library.
Know the cost before anything moves.
A fixed-price assessment gives you the inventory, the risk score and a phased plan. Scope and cost are fixed before the migration starts.
Book a Fixed-Price AssessmentGet in touch
Talk to a modernization engineer
Tell us what you run today. An engineer, not a sales script, replies within one business day.