Ensure you’ve the right Eclipse and Server version
Ensure that you’re using at least Eclipse IDE for Enterprise Java developers (with the Enterprise). It contains development tools to create dynamic web projects and easily integrate servletcontainers (those tools are part of Web Tools Platform, WTP). In case you already had Eclipse IDE for Java (without Enterprise), and manually installed some related plugins, then chances are that it wasn’t done properly. You’d best trash it and grab the real Eclipse IDE for Enterprise Java one.
You also need to ensure that you already have a servletcontainer installed on your machine which implements at least the same Servlet API version as the servletcontainer in the production environment, for example Apache Tomcat, Oracle GlassFish, JBoss AS/WildFly, etc. Usually, just downloading the ZIP file and extracting it is sufficient. In case of Tomcat, do not download the EXE format, that’s only for Windows based production environments. See also a.o. Several ports (8005, 8080, 8009) required by Tomcat Server at localhost are already in use.
A servletcontainer is a concrete implementation of the Servlet API. Note that the Java EE SDK download at Oracle.com basically contains GlassFish. So if you happen to already have downloaded Java EE SDK, then you basically already have GlassFish. Also note that for example GlassFish and JBoss AS/WildFly are more than just a servletcontainer, they also supports JSF, EJB, JPA and all other Java EE fanciness. See also a.o. What exactly is Java EE?
Ensure that you’re using the right Servlet package
javax.* package has been renamed to
jakarta.* package since Servlet API version 5.0 which is part of Jakarta EE 9 (Tomcat 10, TomEE 9, WildFly 22 Preview, GlassFish 6, Payara 6, Liberty 22, etc). So if you’re targeting these server versions or newer, then you need to replace
import javax.servlet.*; import javax.servlet.http.*;
import jakarta.servlet.*; import jakarta.servlet.http.*;
in order to get it to compile, else you might risk to face this build error
The superclass “javax.servlet.http.HttpServlet” was not found on the Java Build Path
Integrate Server in Eclipse and associate it with Project
Once having installed both Eclipse for Enterprise Java and a servletcontainer on your machine, do the following steps in Eclipse:
Integrate servletcontainer in Eclipse
a. Via Servers view
Open the Servers view in the bottom box.
Rightclick there and choose New > Server.
Pick the appropriate servletcontainer make and version and walk through the wizard.
b. Or, via Eclipse preferences
Open Window > Preferences > Server > Runtime Environments.
You can Add, Edit and Remove servers here.
Associate server with project
a. In new project
Open the Project Navigator/Explorer on the left hand side.
Rightclick there and choose New > Project and then in menu Web > Dynamic Web Project.
In the wizard, set the Target Runtime to the integrated server.
b. Or, in existing project
Rightclick project and choose Properties.
In Targeted Runtimes section, select the integrated server.
Either way, Eclipse will then automatically take the servletcontainer’s libraries in the build path. This way you’ll be able to import and use the Servlet API.
Never carry around loose server-specific JAR files
You should in any case not have the need to fiddle around in the Build Path property of the project. You should above all never manually copy/download/move/include the individual servletcontainer-specific libraries like
javaee.jar, etc. It would only lead to future portability, compatibility, classpath and maintainability troubles, because your webapp would not work when it’s deployed to a servletcontainer of a different make/version than where those libraries are originally obtained from.
In case you’re using Maven, you need to make absolutely sure that servletcontainer-specific libraries which are already provided by the target runtime are marked as
<scope>provided</scope>. You can find examples of proper
pom.xml dependency declarations for Tomcat 10+, Tomcat 9-, JEE 9+ and JEE 8- in this answer: Tomcat 9 casting servlets to javax.servlet.Servlet instead of jakarta.servlet.http.HttpServlet
Here are some typical exceptions which you can get when you litter the
/WEB-INF/lib or even
/JRE/lib/ext, etc with servletcontainer-specific libraries in a careless attempt to fix the compilation errors:
- java.lang.NullPointerException at org.apache.jsp.index_jsp._jspInit
- java.lang.NoClassDefFoundError: javax/el/ELResolver
- java.lang.NoSuchFieldError: IS_DIR
- java.lang.NoSuchMethodError: javax.servlet.jsp.PageContext.getELContext()Ljavax/el/ELContext;
- java.lang.AbstractMethodError: javax.servlet.jsp.JspFactory.getJspApplicationContext(Ljavax/servlet/ServletContext;)Ljavax/servlet/jsp/JspApplicationContext;
- org.apache.jasper.JasperException: The method getJspApplicationContext(ServletContext) is undefined for the type JspFactory
- java.lang.VerifyError: (class: org/apache/jasper/runtime/JspApplicationContextImpl, method: createELResolver signature: ()Ljavax/el/ELResolver;) Incompatible argument to function
- jar not loaded. See Servlet Spec 2.3, section 9.7.2. Offending class: javax/servlet/Servlet.class