Javax To Jakarta Migration
GitHubOfficialFirst committed by thevinodkumarDistributed by GitHub
- Skill
- Workflow
- Software development
- MIT
- No issues found
AutoGineer summary
Written by AutoGineer from the skill’s own files, not by the author
This skill provides a structured workflow for migrating Java applications from the legacy javax.* namespace to the modern jakarta.* namespace, a requirement for upgrading to Jakarta EE or newer versions of Apache Tomcat. It emphasizes a safe, step-by-step approach that includes verifying the baseline, updating dependencies, modifying source code, and updating configuration files like web.xml. The skill explicitly distinguishes between migratable Jakarta EE packages and protected JDK-native javax packages.
What it does
- Scans source code for migratable javax.* imports.
- Provides mapping tables for updating Maven or Gradle dependency coordinates.
- Guides the update of web.xml and other configuration files to match target Jakarta EE versions.
- Ensures JDK-native packages like javax.sql or javax.crypto remain untouched.
- Includes verification steps to ensure compilation and test success after migration.
- Provides a summary of all changes and manual steps performed.
When to use it
- When explicitly requested to migrate a project to the jakarta.* namespace.
- When upgrading to Tomcat 10, 11, or newer Jakarta EE versions.
- When delegated by a broader java-upgrade or spring-boot-4-migration task.
Advantages
- Reduces manual effort and risk of errors during namespace refactoring.
- Prevents accidental modification of essential JDK-native packages.
- Ensures compatibility with modern Jakarta EE runtime environments.
- Provides a clear, verifiable procedure for complex dependency updates.
Usage examples
- “Migrate this project to Jakarta EE 10.”
- The agent will verify the current build, identify all relevant javax.* imports, update the pom.xml dependencies to Jakarta EE 10 versions, update web.xml, and perform a final build verification.
- “I am upgrading my application to Tomcat 10.1, please handle the namespace migration.”
- The agent will follow the migration procedure to replace javax.* imports with jakarta.* equivalents, ensuring the project aligns with the Servlet 6.0 requirements for Tomcat 10.1.
Install
Download the skill as a ZIP:
https://mp-staging.autogineer.com/agent-skills/github/javax-to-jakarta-migration/downloadUnzip it into the cross-client skills folder of your project:
mkdir -p .agents/skills && unzip javax-to-jakarta-migration.zip -d .agents/skills
Documentation by thevinodkumar
javax → jakarta Migration Skill
When to Use
The user explicitly asks to migrate to the jakarta namespace, Tomcat 10+/11 or Jakarta EE
java-upgradeorspring-boot-4-migrationdelegates the namespace migration
Detecting javax.* imports alone does not authorize this migration; report them instead.
In Spring Boot projects, the Boot BOM manages Jakarta versions: do not pin the versions below, and let the Boot version decide the Jakarta EE level (Boot 4 = Jakarta EE 11, Servlet 6.1). The examples below target Jakarta EE 10 (Servlet 6.0, Tomcat 10.1+) in non-Boot projects.
Procedure
Step 0 — Baseline
Run ./mvnw verify or ./gradlew build first and record the result; do not migrate on a red baseline. Make the change in a dedicated commit/step.
Step 1 — Scan for javax Usage
Search the codebase for all javax.* imports that need migration:
javax.servlet.* → jakarta.servlet.*
javax.persistence.* → jakarta.persistence.*
javax.validation.* → jakarta.validation.*
javax.annotation.* → jakarta.annotation.*
javax.inject.* → jakarta.inject.*
javax.enterprise.* → jakarta.enterprise.*
javax.faces.* → jakarta.faces.*
javax.ws.rs.* → jakarta.ws.rs.*
javax.el.* → jakarta.el.*
javax.json.* → jakarta.json.*
javax.mail.* → jakarta.mail.*
javax.websocket.* → jakarta.websocket.*Do NOT migrate these (they remain in javax.*):
javax.sql.*— part of JDKjavax.naming.*— part of JDK (JNDI)javax.crypto.*— part of JDKjavax.net.*— part of JDKjavax.security.auth.*— part of JDKjavax.swing.*,javax.xml.parsers.*— JDK packages
Step 2 — Update pom.xml
Replace dependency coordinates. Choose API versions that match the target runtime; the table below is for Jakarta EE 10 (Tomcat 10.1+, Servlet 6.0):
| Target runtime | Jakarta EE | Servlet | Persistence | Validation | Annotations |
|---|---|---|---|---|---|
| Tomcat 10.0 | 9 | 5.0 | 3.0 | 3.0 | 2.0 |
| Tomcat 10.1 | 10 | 6.0 | 3.1 | 3.0 | 2.1 |
| Tomcat 11 | 11 | 6.1 | 3.2 | 3.1 | 3.0 |
| Old | New |
|---|---|
javax.servlet:javax.servlet-api | jakarta.servlet:jakarta.servlet-api:6.0.0 |
javax.persistence:javax.persistence-api | jakarta.persistence:jakarta.persistence-api:3.1.0 |
javax.validation:validation-api | jakarta.validation:jakarta.validation-api:3.0.2 |
javax.annotation:javax.annotation-api | jakarta.annotation:jakarta.annotation-api:2.1.1 |
Step 3 — Update web.xml (if present)
The version must match the target Servlet level (5.0 for Tomcat 10.0, 6.0 for Tomcat 10.1, 6.1 for Tomcat 11); the example below is for Servlet 6.0:
<!-- Old namespace -->
<web-app xmlns="http://xmlns.jcp.org/xml/ns/javaee" version="4.0">
<!-- New namespace -->
<web-app xmlns="https://jakarta.ee/xml/ns/jakartaee" version="6.0">Step 4 — Update Java Source Files
Replace only the Jakarta EE javax. imports identified in Step 1 with their jakarta. equivalents in .java files; leave JDK packages (for example javax.sql, javax.crypto) unchanged. Also check non-Java references: persistence.xml (javax.persistence.* properties), META-INF/services, beans.xml, properties/YAML, string class names and reflection.
Step 5 — Verify
Run
mvn clean compileorgradlew build— fix any compilation errorsRun
mvn testorgradlew test— ensure all tests passSearch for any remaining
javax.*imports (excluding JDK packages)
Upstream sources (read before migrating)
Fetch the page for the target version; prefer it over this skill when they conflict.
Jakarta EE specifications: https://jakarta.ee/specifications/
Eclipse Transformer (binary/bytecode transformation): https://github.com/eclipse-transformer/transformer
OpenRewrite
org.openrewrite.java.migrate.jakarta.JavaxMigrationToJakarta: https://docs.openrewrite.org/recipes/java/migrate/jakarta/javaxmigrationtojakartaTomcat 9 to 10 migration: https://tomcat.apache.org/migration-10.html
Hibernate migration guides: https://hibernate.org/orm/documentation/migrate/
Spring Boot 3 upgrade (Jakarta EE 9+ baseline): https://docs.spring.io/spring-boot/upgrading.html
Output
Provide a migration summary listing all files changed, imports replaced, and any manual steps required.
Files
- ATTRIBUTION.mdAdded by AutoGineer895 B
- LICENSELicence file added by AutoGineer1.0 KiB
- SKILL.md4.8 KiB
Requirements and compatibility
Written for: GitHub Copilot, Claude Code
Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta
“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.
Needs: Claude Code frontmatter
Security
No issues found by our static scan· No issues found
A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.
Attribution and licence
- First committed by
thevinodkumar
- Publisher
- GitHub (Official)
- Distributed by
- GitHub
- Source
- github/awesome-copilot · skills/javax-to-jakarta-migration · commit 797337f
- Licence
- MIT License (redistribution allowed)
- LICENSE (added by AutoGineer from LICENSE)
- ATTRIBUTION.md (written by AutoGineer)
- Synced
- Contributors
- jdubois, thevinodkumar
AutoGineer is not affiliated with or endorsed by thevinodkumar or GitHub.
Download ZIP
The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download javax-to-jakarta-migration.zip