Servlet/Jakarta Release History

How Is Jakarta Servlet Support Determined?

Jakarta Servlet does not follow a standalone support lifecycle. Instead, its support is tied directly to the Jakarta EE platform version it ships with -- when the platform is actively maintained by the Eclipse Foundation and its vendor community, the Servlet specification it includes is considered supported.

In practice, this means your Servlet version's longevity depends on two things: which Jakarta EE platform it belongs to, and whether your application server vendor (Tomcat, Jetty, WildFly, GlassFish, etc.) continues to ship security patches for that platform generation.

Unlike runtimes such as Java SE or Node.js, the Eclipse Foundation does not publish EOL dates for individual Servlet specification versions. Support ends when the ecosystem around it -- your app server, your Jakarta EE implementation, and your Java SE version -- stops receiving updates.

For authoritative guidance, refer to the Jakarta Servlet specification page and your application server vendor's own support roadmap.

What Are the Real Risks of Running an Outdated Servlet Version?

The most immediate risk with older Servlet versions is not a missing patch from the Eclipse Foundation -- it is dependency incompatibility. Modern frameworks like Spring Boot, Jakarta Faces, and CDI tie their minimum requirements to specific Servlet API versions. If your Servlet version lags behind, you are locked out of framework upgrades.

The namespace migration is the sharpest risk in the Servlet ecosystem. Code written against javax.servlet (Servlet 4.0 and below) is not binary-compatible with containers expecting jakarta.servlet (Servlet 5.0 and above). Mixing both in the same deployment will cause ClassNotFoundException or silent runtime failures that are notoriously hard to debug.

Key risk areas to watch

What Actually Happens When a Servlet Specification Becomes Obsolete?

The Eclipse Foundation does not "end" a Servlet specification the way vendors retire a software product. A spec version simply stops evolving -- no new features, no errata, no updates. What changes over time is the world around it: app servers drop support, Java SE versions that the spec requires reach EOL, and library authors stop testing against old containers.

The practical turning point for most teams happens at the app server level. Once Apache Tomcat or Eclipse Jetty stops backporting security patches to the version that implements your Servlet spec, you are effectively running unsupported infrastructure regardless of what the specification document says.

The javax.servlet to jakarta.servlet namespace break -- introduced in Servlet 5.0 -- is a concrete example of how obsolescence plays out in this ecosystem. Applications that never migrated cannot use any library that has dropped javax.servlet support, which now includes the majority of the Jakarta EE ecosystem. That is a harder wall than a typical EOL date.

Most teams find that the migration trigger is not end-of-life notices from Eclipse, but rather a dependency upgrade that demands a newer Servlet API. Plan your upgrade path around your application server vendor's support schedule and your framework requirements, not a centralized EOL calendar.

How Do You Check Which Servlet Version Your Application Is Using?

There are several ways to determine your Servlet API version, depending on whether you are looking at your build config, your running container, or the bytecode itself.

Check via Maven dependency

If your project uses Maven, look for the Servlet API dependency in your pom.xml:

<!-- Jakarta namespace (Servlet 5.0+) -->
<dependency>
  <groupId>jakarta.servlet</groupId>
  <artifactId>jakarta.servlet-api</artifactId>
</dependency>

<!-- Legacy javax namespace (Servlet 4.0 and below) -->
<dependency>
  <groupId>javax.servlet</groupId>
  <artifactId>javax.servlet-api</artifactId>
</dependency>

The groupId alone tells you which namespace generation you are on. You can also run:

mvn dependency:tree | grep servlet

Check via Gradle

./gradlew dependencies --configuration compileClasspath | grep servlet

Check at runtime inside a Servlet

From within a running servlet, you can query the container's Servlet spec version programmatically:

int major = getServletContext().getMajorVersion();
int minor = getServletContext().getMinorVersion();
// e.g., major=6, minor=1 means Servlet 6.1

Check via Apache Tomcat

If you are using Apache Tomcat as your container, the Servlet spec version is tied to your Tomcat version. You can check it from the command line:

catalina.sh version

The output will include a line such as Servlet specification version: 6.0.

Note that the version reported by the container is the spec version the container implements, which may differ from the API version your application was compiled against. Both should be checked.