The superclass “javax.servlet.http.HttpServlet” was not found

The Eclipse error The superclass “javax.servlet.http.HttpServlet” was not found on the Java Build Path means that the servlet API JAR is missing from the project build path, so Eclipse cannot compile a class that extends HttpServlet. The quickest fix is to add the servlet API as a provided Maven dependency, or to add the server runtime (such as Apache Tomcat) to the project.

We see this error mostly after importing an existing Maven web project into Eclipse, after creating a dynamic web project without a target runtime, or after moving a project from Tomcat 9 to Tomcat 10.1 or 11. In 2026, the first thing to check is the package name, because Tomcat 10.1 and 11 use jakarta.servlet, not javax.servlet.

The following example is a servlet for Tomcat 10.1 or 11 with the matching imports. It compiles once jakarta.servlet-api is on the build path.

import jakarta.servlet.http.HttpServlet;          // Servlet 6.x (Tomcat 10.1 and 11)
import jakarta.servlet.http.HttpServletRequest;
import jakarta.servlet.http.HttpServletResponse;

public class RecipeServlet extends HttpServlet {   // compiles with jakarta.servlet-api 6.1.0

    @Override
    protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws java.io.IOException {
        resp.getWriter().write("Pancakes");
    }
}

<dependency>
    <groupId>jakarta.servlet</groupId>
    <artifactId>jakarta.servlet-api</artifactId>
    <version>6.1.0</version>
    <scope>provided</scope>
</dependency>

Notice the provided scope, because the server already ships the servlet API at runtime. We go through both fixes in Eclipse, the choice between javax and jakarta for each Tomcat version, the same error on JSP files, and what to check when the red marker stays.

1. Why HttpServlet Is Not Found on the Build Path

Every servlet extends HttpServlet, and that class is not part of the JDK. It comes from the servlet API, which the servlet container (Tomcat, Jetty, WildFly) provides. A plain Java project in Eclipse has only the JDK on its build path, so the compiler marks the class declaration with this error and refuses to build it.

The same project compiled on the command line gives a clearer message. With only jakarta.servlet-api on the class path, a servlet that still imports javax.servlet fails on JDK 25 like this.

RecipeServlet.java:3: error: package javax.servlet.http does not exist
import javax.servlet.http.HttpServlet;
                         ^
RecipeServlet.java:5: error: cannot find symbol
public class RecipeServlet extends HttpServlet {
                                   ^
  symbol: class HttpServlet
2 errors

So the error has two common causes. Either the servlet API JAR is not on the build path at all, or the JAR is there but has a different package name (jakarta) than the imports in our code (javax).

2. Solution

To include the servlet API in the build path, we have two options. A Maven or Gradle project should declare the dependency, because the build works the same way in Eclipse, IntelliJ IDEA and on the CI server. A dynamic web project without a build tool gets the API from the server runtime.

2.1. Add the Target Server Runtime

In this solution, we add the server runtime to the project as a targeted runtime. The server runtime already contains the servlet and JSP API JARs, so Eclipse puts them on the build path and the error goes away. Follow these steps in Eclipse IDE for Enterprise Java and Web Developers.

1. Open Window > Preferences > Server > Runtime Environments, click Add, pick Apache Tomcat v11.0 (or the version we deploy to) and point it to the Tomcat installation folder.
2. Right-click the project and open Properties > Targeted Runtimes.
3. Check the Tomcat runtime and click Apply and Close.
4. If the error is still shown, open Properties > Project Facets, select the Runtimes tab and check the same runtime there.

The targeted runtime is an Eclipse setting only. Maven and Gradle do not see it, so a build on the command line still fails until the project declares the dependency from the next section.

2.2. Add the Servlet API Maven Dependency

Another option is to add the servlet API dependency to pom.xml. The artifact depends on the server we deploy to, as listed on the Tomcat version page. For Tomcat 11, Jakarta EE 11 servers and Spring Boot 4, we use jakarta.servlet-api 6.1.0, as in the intro. For Tomcat 10.1 and other Jakarta EE 10 servers, we use 6.0.0.

<dependency>
    <groupId>jakarta.servlet</groupId>
    <artifactId>jakarta.servlet-api</artifactId>
    <version>6.0.0</version>
    <scope>provided</scope>
</dependency>

Only projects that still run on Tomcat 9 or another Java EE 8 server use the old javax artifact. Its last version is 4.0.1, and it keeps the javax.servlet package names.

<dependency>
    <groupId>javax.servlet</groupId>
    <artifactId>javax.servlet-api</artifactId>
    <version>4.0.1</version>
    <scope>provided</scope>
</dependency>

After saving pom.xml, right-click the project and select Maven > Update Project (Alt+F5), so Eclipse reloads the dependencies. There is no mvn update command. On the command line, mvn clean package downloads the JAR and compiles the project.

Keep the scope provided, because a servlet API JAR inside WEB-INF/lib clashes with the copy that the server already has. Tomcat always loads the Servlet, JSP, EL and WebSocket API classes from its own lib folder first, so the duplicate JAR adds nothing there and can cause class loading errors on other servers.

2.3. Add the Dependency in Gradle

Gradle has no provided scope. The compileOnly configuration does the same job, because it puts the JAR on the compile class path and leaves it out of the WAR file. After the change, right-click the project and select Gradle > Refresh Gradle Project.

dependencies {
    compileOnly 'jakarta.servlet:jakarta.servlet-api:6.1.0'
}

The war plugin also offers providedCompile, which works the same way for WAR projects.

3. javax or jakarta? Matching the Servlet API to the Server

Java EE moved to the Eclipse Foundation and became Jakarta EE. Since Servlet 5.0, every package starts with jakarta instead of javax, so javax.servlet.http.HttpServlet became jakarta.servlet.http.HttpServlet. The class is the same, but the JVM treats the two names as unrelated types.

The server decides which name our code must use. The versions come from the Apache Tomcat version table and the Jakarta Servlet 6.1 specification.

Server	Servlet version	Maven artifact	Package in imports
Tomcat 9.0 (Java EE 8)	4.0	javax.servlet:javax.servlet-api:4.0.1	javax.servlet
Tomcat 10.1 (Jakarta EE 10)	6.0	jakarta.servlet:jakarta.servlet-api:6.0.0	jakarta.servlet
Tomcat 11.0 (Jakarta EE 11)	6.1	jakarta.servlet:jakarta.servlet-api:6.1.0	jakarta.servlet
Spring Boot 4 (embedded Tomcat 11)	6.1	none, it comes with spring-boot-starter-webmvc	jakarta.servlet

A mixed setup is the trap. Code with javax imports compiles against javax.servlet-api, but Tomcat 10.1 and 11 ignore a javax @WebServlet annotation, so the URL returns 404. A servlet declared in web.xml fails to load with NoClassDefFoundError: javax/servlet/http/HttpServlet. The fix is to change the imports to jakarta and the dependency to jakarta.servlet-api, or to convert an old WAR with the Apache Tomcat migration tool for Jakarta EE.

For example, a team imports a 2019 order-tracking project with javax imports into a current Eclipse release and adds Tomcat 11 as the runtime. Every servlet shows the build path error, because Tomcat 11 provides only jakarta.servlet. Adding javax.servlet-api removes the red markers, but the pages return 404 after deployment. The real fix is a search-and-replace of javax.servlet with jakarta.servlet in the sources and in web.xml, plus the 6.1.0 dependency.

4. The Same Error on JSP Files

Eclipse also shows the message on JSP files, even when the project has no servlet class at all. The JSP validator translates each page into a servlet that extends HttpServlet, so it needs the same API on the build path. The JSP API (jakarta.servlet.jsp-api) is a separate JAR.

A server runtime from section 2 brings both JARs. With Maven, we add the JSP API next to the servlet API, again with provided scope. Version 4.0.0 matches Tomcat 11, and 3.1.1 matches Tomcat 10.1.

<dependency>
    <groupId>jakarta.servlet.jsp</groupId>
    <artifactId>jakarta.servlet.jsp-api</artifactId>
    <version>4.0.0</version>
    <scope>provided</scope>
</dependency>

5. When the Error Stays After the Fix

Eclipse caches the build path and the validation results, so the marker sometimes survives a correct fix. Go through these checks in order.

• Run Maven > Update Project and check Force Update of Snapshots/Releases if a download failed earlier.
• Run Project > Clean to rebuild the project and refresh the markers in the Problems view.
• Open Properties > Java Build Path > Libraries and confirm that Maven Dependencies or the server runtime library is listed.
• Search the sources for import javax.servlet when the server is Tomcat 10.1 or 11.
• Delete a broken JAR from the local Maven repository (~/.m2/repository/jakarta/servlet) and update the project again.

A related compile error, HttpServlet cannot be resolved to a type, has the same causes and the same fixes. The guide to creating a Maven web project in Eclipse shows a clean project setup from the start.

6. HttpServlet Build Path FAQs

The fix changes a little with Spring Boot, with IntelliJ IDEA and in projects without a build tool, and the provided scope needs its own explanation.

6.1. Why does the servlet API dependency use provided scope?

Because the server supplies the servlet API at runtime. The provided scope puts the JAR on the compile class path and keeps it out of the WAR file. The Maven dependency scopes guide compares all scopes.

6.2. Does a Spring Boot application need the servlet API dependency?

No. The spring-boot-starter-webmvc starter (named spring-boot-starter-web before Spring Boot 4) pulls in tomcat-embed-core, which contains the jakarta.servlet classes. We add jakarta.servlet-api as provided only when we deploy a Spring Boot WAR to an external Tomcat and the starter Tomcat is marked provided too.

6.3. How do I fix the same error in IntelliJ IDEA?

IntelliJ IDEA reads the dependencies from pom.xml or build.gradle, so we add jakarta.servlet-api as shown in section 2 and click Reload All Maven Projects. For a project without a build tool, we add the Tomcat lib/servlet-api.jar under File > Project Structure > Modules > Dependencies.

6.4. Can I add the servlet-api.jar from the Tomcat lib folder by hand?

Yes, it works for a quick test, because servlet-api.jar in TOMCAT_HOME/lib contains HttpServlet. It ties the project to one folder on one machine, so a Maven dependency or a targeted runtime is the better long-term fix.

7. Conclusion

Eclipse shows The superclass “javax.servlet.http.HttpServlet” was not found on the Java Build Path whenever the project has no servlet API on its build path. We fix it with a provided dependency on the servlet API, or with a targeted server runtime for projects without a build tool.

The package name matters as much as the JAR. Tomcat 10.1, Tomcat 11 and Spring Boot 4 need jakarta.servlet imports with jakarta.servlet-api 6.0.0 or 6.1.0, while only Tomcat 9 projects keep javax.servlet-api 4.0.1. For more on servlets, read the Java servlets tutorial, and the guide to checked and unchecked exceptions shows where errors such as NoClassDefFoundError sit in the Throwable hierarchy.

8. References

• Apache Tomcat, Which Version Do I Want?
• Jakarta Servlet 6.1 Specification
• Eclipse Help, Specifying Target Servers
• Maven, Dependency Scope
• Apache Tomcat 10 Migration Guide

Happy Learning !!

Source Code on Github