Home » Java » Unable to compile class for JSP: The type java.util.Map$Entry cannot be resolved. It is indirectly referenced from required .class files

Unable to compile class for JSP: The type java.util.Map$Entry cannot be resolved. It is indirectly referenced from required .class files

Posted by: admin November 17, 2021 Leave a comment


I can’t get tomcat7 to compile jsps. It till run the example servlets just fine and the service is up and running. I am running oracle java 8.

Can anyone point me in the right direction?

Here is the stacktrace:

type Exception report

message Unable to compile class for JSP:

description The server encountered an internal error that prevented it from fulfilling this request.


org.apache.jasper.JasperException: Unable to compile class for JSP: 

An error occurred at line: 1 in the generated java file
The type java.util.Map$Entry cannot be resolved. It is indirectly referenced from required .class files

note The full stack trace of the root cause is available in the Apache Tomcat/7.0.35 logs.

The code looks like this and it’s the sample code from tomcat7 so my guess is that it’s correct.

<%@ taglib prefix="mytag" uri="/WEB-INF/jsp2/jsp2-example-taglib.tld" %>
  <title>JSP 2.0 Examples - Hello World SimpleTag Handler</title>
<h1>JSP 2.0 Examples - Hello World SimpleTag Handler</h1>
<p>This tag handler simply echos "Hello, World!"  It's an example of
a very basic SimpleTag handler with no body.</p>

You must use a more recent version of tomcat which has support for JDK 8.

I can confirm that apache-tomcat-7.0.35 does NOT have support for JDK8, I can also confirm that apache-tomcat-7.0.50 DOES have support for JDK8.


The class format of JDK8 has changed and thats the reason why Tomcat is not able to compile JSPs. Try to get a newer version of Tomcat.

I recently had the same problem. This is a bug in Tomcat, or rather, JDK 8 has a slightly different class file format than what prior-JDK8 versions had. This causes inconsistency and Tomcat is not able to compile JSPs in JDK8.

See following references:


If you are using maven then you can add the tomcat7-maven-plugin to your pom.xml and it shall run fine. This plugin will run the project on Tomcat servlet container version 7.0.47 which supports JDK 1.8.

<!-- Include context file for Datasource configuration -->
<!-- Include jdbc driver dependency if using datasource (in my case oracle) -->

Hope this is useful!


Because we are running on Ubuntu 12.04 LTS and the latest official supported tomcat7 package is 7.0.26 we are not easily able to update the whole tomcat.

I order to test for with the jdk8, I was able to get resolve this issue by changing some jars against their latest 7.0.* version.

I switched jasper.jar, jasper-el and tomcat-util to the version 7.0.53 and added ecj-4.3.1.jar. That brings the application back online.

BUT… also i changed packaged content with this, so maybe it would be better to download the whole tomcat and use it self installed as messing up packages. So please see this only as a very dirty quickhack or workaround.


Faced exactly the same issue while upgrading my application from java 6 to java 8 on tomcat 7.0.19.
After upgrading the tomcat to 7.0.59, this issue is resolved.


Try and add <%@page import="java.util.Map.Entry"%> to your jsp file


There are a lot of correct/same answers, but for future references:

Same stands for Tomcat 7. Be aware that updating only your used frameworks’ versions (as proposed in other similar questions) isn’t enough.

You also have to update Tomcat plugin’s version.
What worked for me, using Java 7, was upgrading to version 2.2 of tomcat7-maven-plugin (= Tomcat 7.0.47).


I recently get across the same issue. I was using IntelliJx64 with Tomcat7.0.32 with jdk.8.0.102. There was no issue then. I was able to directly access my deployment localhost:[port] without adding [mywebapp] or /ROOT.

When I tried to migrate to eclipse neon, I came across the same bug that is discussed when I tried to set the path as empty string. When I enforced execution environment to Java7 and set modules to empty it did not solve toe issue. However, when I changed my tomcat installation to 7.072 and manually changed context path configuration to path=”” the problem was solved in eclipse. (You can manipulate the path via double click server and switching to module tab too.)

My wonder is how come IntelliJ was not giving any issues with the same bug which was supposed to be related to tomcat installation version?

There also seems to be a relation with the IDE in use.


I ran into this before, as others said: just upgrade jetty plugin

if you are using maven

go to jetty plugin in pom.xml and update it to


hope this help you


From the JIRA knowledge base:


Workflow actions may be inaccessible

  1. JIRA may throw exceptions on screen
  2. One or both of the following conditions may exist:

The following appears in the atlassian-jira.log:

     2007-12-06 10:55:05,327 http-8080-Processor20 ERROR [500ErrorPage] 
     Exception caught in500 page Unable to compile class for JSP
    org.apache.jasper.JasperException: Unable to compile class for JSP
   at org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:572)
   at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:305)



The Tomcat container caches .java and .class files generated by the
JSP parser they are used by the web application. Sometimes these get
corrupted or cannot be found. This may occur after a patch or upgrade
that contains modifications to JSPs.


1.Delete the contents of the /work folder if using standalone JIRA or /work if using EAR/WAR installation
2. Verify the user running the JIRA application process has Read/Write permission to the /work directory.
3. Restart the JIRA application container to rebuild the files.


Add this import <%@page import="java.util.Map" %>

This worked for me, but I also needed to add <%@ page import=”java.util.HashMap” %>.
It seems that the above answer is true, that if you have the newer tomcat you might not need to add these lines, but as I could not change my whole system, this worked.
Thank you