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.

score 1 · Accepted Answer · edited May 23 '17 at 09:58

1

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.

edited May 23 '17 at 09:58

Community

1
1

answered Feb 02 '11 at 04:42

gigadot

8,879
7
35
51

I'm compiling both of them on linux. I'll take a look at the war files and see if there are any differences. – Vivin Paliath Feb 02 '11 at 16:41
If the projects are identical, I would expect the same maven version to bundle them in the same way. Do you happen to have any other version of `el-api` in the project that doesn't work? I don't know what the problem is but I suggest you try to remove `el-api-2.2.jar` from a war file that doesn't work using any zip program and deploy it to test whether it is really because of this extra library. BTW, make sure you do `mvn clean` to ensure that there is nothing left over from old build. – gigadot Feb 02 '11 at 20:26
Some IDE supports maven dependency graph, you might, as well, look into where the `el-api` come from. Since `el` is part of Java EE, you might not need to include it if it is already provided by your servlet container. You just need to declare `el-api` scope to be `provided` in maven dependency. – gigadot Feb 02 '11 at 20:38
Just wondering whether you are certain that the right Java is used for compilation on both machine. Are they both JDK SE or EE or OpenJDK? – gigadot Feb 02 '11 at 20:42
They're both running the JDK from Sun. I never use OpenJDK. – Vivin Paliath Feb 20 '11 at 17:32
I just wanted to update this. I was eventually able to get this to work by using the proper dependencies in `pom.xml`. I was pulling something in that was somehow clobbering `el-api` (probably via a transitive dependency or something), which was causing this problem on that one machine. Still not sure why it worked on one vs. the other though. – Vivin Paliath Nov 12 '13 at 22:18

score 0 · Answer 2 · edited May 23 '17 at 11:49

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.

score 0 · Answer 3 · answered Dec 24 '14 at 17:14

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

Check the cglibs in my classpath.
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.

score 0 · Answer 4 · edited Apr 29 '13 at 06:58

0

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?

edited Apr 29 '13 at 06:58

Arjan Tijms

37,782
12
108
140

answered Feb 02 '11 at 07:54

Raghuram

51,854
11
110
122

java.lang.VerifyError: Incompatible argument to function

4 Answers4