Spring Boot 3.0 moved to the versions of Jakarta EE specifications in Jakarta EE 10, which replaced javax packages with jakarta packages and changed some dependency coordinates. For scans, this means old javax artifacts left in your tree are a sign of libraries that were not migrated and deserve a closer look.
What changed
The Spring Boot 3.0 migration guide says that whenever Spring Boot depends on a Jakarta EE specification it upgraded to the Jakarta EE 10 version, for example Servlet 6.0 and JPA 3.1. It adds that older Java EE dependencies must no longer be used directly or transitively in your build, and gives an example: use jakarta.servlet:jakarta.servlet-api rather than javax.servlet:javax.servlet-api.
There are two kinds of change:
| Change | Example |
|---|---|
| Dependency coordinates | jakarta.servlet-api replaces javax.servlet-api |
| Package names in code | import statements move from javax to jakarta |
The guide lists tools to help, including OpenRewrite recipes.
Why scanners care
A scanner reads coordinates and versions. After a migration, two things stand out in the inventory:
- Duplicate APIs. If both a javax and a jakarta servlet API appear, something in the tree pulls the old one. That can mean a library that has not been updated for the newer platform.
- Old libraries held back. A dependency that still needs javax may be stuck on an older release line, which can affect how quickly fixes reach you. Check each one's release notes rather than assuming.
A scan result for the old artifact is not wrong, it is a pointer. Use the dependency tree to see who requires it. Our guide to finding who pulls a library onto your classpath shows the commands.
Steps
- Generate a full dependency inventory for the migrated build.
- Filter for groups starting with javax and for older Java EE group names.
- For each hit, identify the parent dependency that brings it in.
- Check whether the parent has a release for Jakarta EE 10 and upgrade it, or replace it.
- Use exclusions only when you have confirmed nothing needs the old artifact at runtime. See excluding a transitive dependency in Maven.
- Re-scan, and keep the inventory with the release so you can compare it next time.
Do not assume that a clean compile means a clean tree. Maven and Gradle will happily carry both families.
Try it yourself
Click through it at your own pace, or open it full screen. Safeguard scans dependencies, produces SBOMs and uses reachability analysis to show which findings your code can actually reach. You can run a free scan at gold.safeguard.sh/scan.
Quick check
Is a javax dependency a vulnerability?
Not by itself. It indicates an older API family that may come from a library you should review.
Do all Spring Boot 3 apps need the jakarta packages?
The migration guide says Spring Boot 3.0 uses Jakarta EE 10 specifications and jakarta packages, so code that touches those APIs needs the new imports.
Sources
Last reviewed: 19 October 2026.
