Generated banner for Javax To Jakarta Migration
Generated logo for Javax To Jakarta Migration

Javax To Jakarta Migration

GitHubOfficialFirst committed by thevinodkumarDistributed by GitHub

  • Skill
  • Workflow
  • Software development
  • MIT
  • No issues found

From the author

Migrate Java code from javax.* to jakarta.* namespace. Use only when the user explicitly asks for a javax to jakarta namespace or framework migration (for example to Tomcat 10+/11 or Jakarta EE), or when java-upgrade or spring-boot-4-migration delegates it. Finding javax imports alone does not authorize a migration.
— the description by thevinodkumar

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

  1. Download the skill as a ZIP:

    https://mp-staging.autogineer.com/agent-skills/github/javax-to-jakarta-migration/download
  2. Unzip 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-upgrade or spring-boot-4-migration delegates 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 JDK

  • javax.naming.* — part of JDK (JNDI)

  • javax.crypto.* — part of JDK

  • javax.net.* — part of JDK

  • javax.security.auth.* — part of JDK

  • javax.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 runtimeJakarta EEServletPersistenceValidationAnnotations
Tomcat 10.095.03.03.02.0
Tomcat 10.1106.03.13.02.1
Tomcat 11116.13.23.13.0
OldNew
javax.servlet:javax.servlet-apijakarta.servlet:jakarta.servlet-api:6.0.0
javax.persistence:javax.persistence-apijakarta.persistence:jakarta.persistence-api:3.1.0
javax.validation:validation-apijakarta.validation:jakarta.validation-api:3.0.2
javax.annotation:javax.annotation-apijakarta.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
  1. Run mvn clean compile or gradlew build — fix any compilation errors

  2. Run mvn test or gradlew test — ensure all tests pass

  3. Search 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.

Output

Provide a migration summary listing all files changed, imports replaced, and any manual steps required.

Files

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
GitHub avatar of thevinodkumarthevinodkumar
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