java.lang.VerifyError: Incompatible argument to function

Question

I have a mavenized Spring 3 project that builds and runs fine on one machine. The exact same project builds fine on a second machine, but when I try to hit a page (one that works fine on the other machine), I get the following stacktrace:

java.lang.VerifyError: (class: org/apache/jsp/tag/web/generate_002dvalidation_tag, method: _jspx_meth_c_005fset_005f13 signature: (Ljavax/servlet/jsp/tagext/JspTag;Ljavax/servlet/jsp/PageContext;[I)Z) Incompatible argument to function
    java.lang.Class.getDeclaredConstructors0(Native Method)
    java.lang.Class.privateGetDeclaredConstructors(Class.java:2389)
    java.lang.Class.getConstructor0(Class.java:2699)
    java.lang.Class.newInstance0(Class.java:326)
    java.lang.Class.newInstance(Class.java:308)
    org.apache.jasper.compiler.TagFileProcessor.loadTagFile(TagFileProcessor.java:635)
    org.apache.jasper.compiler.TagFileProcessor.access$000(TagFileProcessor.java:52)
    org.apache.jasper.compiler.TagFileProcessor$TagFileLoaderVisitor.visit(TagFileProcessor.java:685)
    org.apache.jasper.compiler.Node$CustomTag.accept(Node.java:1530)
    org.apache.jasper.compiler.Node$Nodes.visit(Node.java:2361)
    org.apache.jasper.compiler.Node$Visitor.visitBody(Node.java:2411)
    org.apache.jasper.compiler.Node$Visitor.visit(Node.java:2417)
    org.apache.jasper.compiler.Node$Root.accept(Node.java:495)
    org.apache.jasper.compiler.Node$Nodes.visit(Node.java:2361)
    org.apache.jasper.compiler.TagFileProcessor.loadTagFiles(TagFileProcessor.java:703)
    org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:210)
    org.apache.jasper.compiler.Compiler.compile(Compiler.java:347)
    org.apache.jasper.compiler.Compiler.compile(Compiler.java:327)
    org.apache.jasper.compiler.Compiler.compile(Compiler.java:314)
    org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:589)
    org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:317)
    org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:313)
    org.apache.jasper.servlet.JspServlet.service(JspServlet.java:260)
    javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
    org.springframework.web.servlet.view.InternalResourceView.renderMergedOutputModel(InternalResourceView.java:238)
    org.springframework.web.servlet.view.AbstractView.render(AbstractView.java:250)
    org.springframework.web.servlet.DispatcherServlet.render(DispatcherServlet.java:1047)
    org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:817)
    org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:719)
    org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:644)
    org.springframework.web.servlet.FrameworkServlet.doGet(FrameworkServlet.java:549)
    javax.servlet.http.HttpServlet.service(HttpServlet.java:617)
    javax.servlet.http.HttpServlet.service(HttpServlet.java:717)

The only difference that I can think of is the version of Java. On the machine where the project works, the version is 6 update 17, whereas on the second machine (where the project does not work), the version is 6 update 22. The pom's are exactly the same.

It looks like the problem is centered around a custom tag, but I can't figure out what it is. What could be causing this problem?

UPDATE

I took a look at the target directories on both machines and noticed the following:

• On the machine where the project doesn't work, the lib directory has el-api-2.2.jar
• On the machine where the project works, there is tomcat directory under target which contains the following:

`-- tomcat
    |-- conf
    |   |-- tomcat-users.xml
    |   `-- web.xml
    |-- logs
    |-- webapps
    `-- work
        `-- localEngine
            `-- localhost
                `-- _
                    |-- org
                    |   `-- apache
                    |       `-- jsp
                    |           |-- tag
                    |           |   `-- web
                    |           |       |-- generate_002dvalidation_tag.class
                    |           |       `-- generate_002dvalidation_tag.java
                    |           `-- WEB_002dINF
                    |               `-- jsp
                    |                   `-- starship
                    `-- SESSIONS.ser

This directory is not present on the machine where the project works

• On the machine where the project works, there is a war directory under target, which is not present on the machine where the project does not work (however both machines produce a war file under the target directory)

• On the machine where the build does not work, the war file is 4,135,195 bytes, whereas on the other it is 4,104,569 bytes. This difference comes from the inclusion of the el-api-2.2.jar file.

I'm not sure what this means.

Answer 1

Though the reason mentioned by gigadot is correct, but I would definitely check below before moving to something else:

1. Check the cglibs in my classpath.
2. Check the hibernate versions in my classpath.

Chances are good that having multiple or conflicting version of any of the above could cause unexpected issues like the one in question.

Answer 2

More than java version, I think the problem is due to the difference in the versions of Java EE libraries.

Is it possible that the two machines have different app servers or different versions of the app server? Also, are the libraries provided by the container (like servlet-api.jar or jsp-api.jar) being packaged in the war?

Answer 3

According to my experience, sometimes the verifications get complex generics-related things wrong. Also, sometimes instrumentation can pose problems to it. If you know that the verification error should not appear, but it still does, verification can be disabled with -noverify startup option.

Sometimes it is also disabled for other reasons such as performance.

For more details on disabling verification, see this thread.

Answer 4

According to this answer,

java.lang.VerifyError can be the result when you have compiled against a different library than you are using at runtime.

I suggest you to compile it on each machine and compare the content within the war file (assumming, from the stacktrace, you are building war project).

Do you happen to compile it on linux vs Windowsy by any chance? It is possible that you may have the same library with the different version within the classpath. On different OS, the order at which the class are loaded are different. The correct one maybe loaded first on your machine running JDK 6u17.

I normally open the war file in a 7zip browser and check whether there are any same library of different versions. Some libraries use the different artifact name but actually the same, e.g. spring-bean and org.springframework.bean.