Jakarta EE Platform Release History

How Does Jakarta EE Handle Version Support?

Jakarta EE does not define end-of-life dates for its specification versions. Unlike runtimes such as Node.js or Python, Jakarta EE is a set of specifications maintained by the Eclipse Foundation -- and the specification itself never officially "expires." What expires is the support from the application server vendors who implement it.

Once the Jakarta EE Working Group releases a new major version, the previous specification receives no further updates. It is not deprecated with a formal EOL date; it simply stops evolving. Whether you can keep running it in production depends entirely on how long your chosen implementation -- GlassFish, WildFly, Payara, TomEE, WebLogic, JBoss EAP, or others -- continues to ship security patches for that version.

The table below reflects the general status pattern across Jakarta EE major versions:

The release cadence follows Java LTS releases roughly every two years. This means each major Jakarta EE version targets a specific Java SE baseline, and upgrading usually requires upgrading your JDK alongside your application server.

References: Jakarta EE Specifications -- Eclipse Foundation | Jakarta EE Specification Process (JESP)

What Are the Real Risks of Running an Older Jakarta EE Version?

The most immediate risk is not a missing security patch in the spec itself -- it is the cascade of incompatibilities that builds up as the rest of the ecosystem moves on. Jakarta EE applications do not run in isolation; they depend on the intersection of your spec version, your app server, your JDK, and your third-party libraries.

Namespace lock-in (javax.* vs jakarta.*)

Jakarta EE 9 introduced a hard namespace break. Code written for Java EE 8 or Jakarta EE 8 uses the javax.* package namespace. Everything from Jakarta EE 9 onwards uses jakarta.*. Libraries, frameworks (Spring, Hibernate, Quarkus), and tooling have progressively dropped javax.* support. If you stay on Jakarta EE 8, you are increasingly cut off from current library versions.

App server vendor dropping your version

The specification itself is frozen -- but your runtime is not. Vendors like Red Hat (JBoss EAP), Payara, IBM (Open Liberty), and Oracle (WebLogic) each publish their own support timelines. Once a vendor drops a Jakarta EE version, you stop receiving CVE patches for the server, even if your application code is untouched. Check the lifecycle page of your specific app server, not just the Jakarta EE spec page.

Missing specifications your dependencies now require

Each Jakarta EE major version adds and updates component specs -- CDI, JPA, Servlet, Jakarta Data, Jakarta Concurrency. If a library you use requires CDI 4.x or Jakarta Data 1.0, those are only available in the current Jakarta EE version, as shown in the release table above. Staying on an older profile version forces you to vendor-patch or shadow these APIs, which is fragile at best.

What Actually Happens When a Newer Jakarta EE Version Supersedes Yours?

Nothing dramatic happens on day one. Your application keeps running, your app server keeps booting. The specification does not have a kill switch. What changes is slower and more cumulative -- and that is exactly what makes it easy to ignore until it becomes a migration crisis.

First, the specification project stops accepting changes. Bug reports against the old version are closed or redirected to the current one. If a flaw exists in how a spec was written, it will not be fixed retroactively.

Second, your application server vendor starts its own countdown. Vendors typically announce a support window when a new Jakarta EE version ships. JBoss EAP, Payara Platform, and Open Liberty all have published lifecycle pages that map which Jakarta EE version each product release supports and for how long. Once your app server version hits end-of-vendor-support, you lose access to security patches regardless of the spec status.

Third, the broader Java ecosystem stops testing against your version. CI pipelines in popular projects drop older Jakarta EE compatibility test profiles. Hibernate, Weld, and other spec implementations prioritize the current spec. In practice, you end up inheriting bugs that were fixed upstream but never backported.

Most teams running a superseded Jakarta EE version are not blocked immediately -- they are paying an accumulating tax of workarounds, pinned dependency versions, and skipped upgrades that eventually forces a larger migration than an incremental one would have required.

How Do You Check Which Jakarta EE Version Your Application Is Targeting?

There are three places to look: your build descriptor, your runtime, and your application server.

Check your Maven pom.xml

The Jakarta EE API dependency in your pom.xml is the authoritative source for which spec version your application is compiled against:

<!-- Jakarta EE 10 full platform -->
<dependency>
  <groupId>jakarta.platform</groupId>
  <artifactId>jakarta.jakartaee-api</artifactId>
  <version>10.0.0</version>
  <scope>provided</scope>
</dependency>

<!-- Or for Jakarta EE 11 -->
<dependency>
  <groupId>jakarta.platform</groupId>
  <artifactId>jakarta.jakartaee-api</artifactId>
  <version>11.0.0</version>
  <scope>provided</scope>
</dependency>

Check at runtime via the Servlet API

You can query the Servlet spec version at runtime, which reflects the Jakarta EE version your app server implements:

// Inside a Servlet or CDI bean
int major = servletContext.getMajorVersion();
int minor = servletContext.getMinorVersion();
System.out.println("Servlet " + major + "." + minor);
// Servlet 6.0 = Jakarta EE 10
// Servlet 6.1 = Jakarta EE 11

Check your application server version

Each application server maps its version to a Jakarta EE spec version. For GlassFish:

asadmin version

For WildFly:

$WILDFLY_HOME/bin/standalone.sh --version

Then cross-reference the server version against the vendor's compatibility matrix -- GlassFish 7.x implements Jakarta EE 10, GlassFish 8.x targets Jakarta EE 11, as shown in the release table above.