Q: java.lang.VerifyError on XPAthConstants.NODESET in WebSphere but not in Jetty My code works fine in Jetty, but as soon as I deploy in WebSphere, I get a java.lang.VerifyError exception with no extra information at all (not even a message).
The code:
Class c = Class.forName("javax.xml.xpath.XPathConstants"); // This works
System.out.println(c.getDeclaredFields()); // This works
System.out.println(c.getDeclaredField("NODESET")); // This works (public static final javax.xml.namespace.QName javax.xml.xpath.XPathConstants.NODESET)
System.out.println(XPathConstants.NODESET); // This fails with an empty java.lang.VeryfyError

XPathConstants is part of the xml.jar shipped with the JRE. Both Jetty and WebSphere are running with a IBM SDK 7, and code is compiled with the same version.
I have no idea where it could come from. Thank you for the help.
Here is the StackTrace, although it says nothing since the VerifyError is empty
[9/17/15 4:56:01:730 CDT] 000001c0 SystemOut     O java.lang.VerifyError
[9/17/15 4:56:01:731 CDT] 000001c0 SystemOut     O      at com.ibm.idwb.common.filenet.linker.LinkerDocumentLevel.findRelationships(LinkerDocumentLevel.java:1352)
[9/17/15 4:56:01:731 CDT] 000001c0 SystemOut     O      at com.ibm.idwb.common.filenet.linker.LinkerDocumentLevel.buildKeyDefCache(LinkerDocumentLevel.java:1119)
[9/17/15 4:56:01:731 CDT] 000001c0 SystemOut     O      at com.ibm.idwb.common.filenet.linker.LinkerDocumentLevel.checkForKeys(LinkerDocumentLevel.java:748)
[9/17/15 4:56:01:731 CDT] 000001c0 SystemOut     O      at com.ibm.idwb.common.filenet.parallel.cmd.LinkRefreshCommand.refreshLinks(LinkRefreshCommand.java:224)
[9/17/15 4:56:01:732 CDT] 000001c0 SystemOut     O      at com.ibm.idwb.common.filenet.parallel.cmd.LinkRefreshCommand.access$1(LinkRefreshCommand.java:197)
[9/17/15 4:56:01:732 CDT] 000001c0 SystemOut     O      at com.ibm.idwb.common.filenet.parallel.cmd.LinkRefreshCommand$1.call(LinkRefreshCommand.java:161)
[9/17/15 4:56:01:732 CDT] 000001c0 SystemOut     O      at com.ibm.idwb.common.filenet.parallel.cmd.LinkRefreshCommand$1.call(LinkRefreshCommand.java:1)
[9/17/15 4:56:01:732 CDT] 000001c0 SystemOut     O      at com.ibm.idwb.common.parallel.executor.CountableTask.call(Unknown Source)
[9/17/15 4:56:01:733 CDT] 000001c0 SystemOut     O      at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:345)
[9/17/15 4:56:01:733 CDT] 000001c0 SystemOut     O      at java.util.concurrent.FutureTask.run(FutureTask.java:177)
[9/17/15 4:56:01:733 CDT] 000001c0 SystemOut     O      at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1121)
[9/17/15 4:56:01:733 CDT] 000001c0 SystemOut     O      at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:614)
[9/17/15 4:56:01:734 CDT] 000001c0 SystemOut     O      at java.lang.Thread.run(Thread.java:777)


A: The missing VerifyError message is a JVM defect, and you should report it to the Java team.
This is very likely a class linkage error.  You very likely have a JAR in your classpath that contains javax.xml.namespace.QName, and it is being preferred to the copy from Liberty (for example, you could be using <classloader delegation="parentLast"/>).  This is the situation:


*

*Application classes:


*

*com.ibm.idwb.common.filenet.linker.LinkerDocumentLevel

*javax.xml.namespace.QName


*Liberty/JDK


*

*javax.xml.xpath.XPathConstants

*javax.xml.namespace.QName



There are two QName classes, but class loaders may only link to one of them; if you try to link to both, you will get an error.  When you use reflection to access the NODESET field, you're only asking the Liberty/JDK class loader to resolve the QName field on behalf of XPathConstants.  When you use a direct field reference, you're additionally asking your application class loader to resolve the XPathConstants class (which it finds from Liberty/JDK) and also the QName class (which it finds in a different place than the Liberty/JDK class loader found it when linking QName to XPathConstants).
You need to either:


*

*Remove parentLast (or whatever is causing the duplicate QName class load)

*Remove the JAR containing the duplicate javax.xml.namespace.QName class from your application class path

*Add a JAR containing a duplicate javax.xml.xpath.XPathConstants class to the application class path so that you fully (rather than partially) duplicate the class hierarchy


(If this analysis is correct, then it's unfortunate that the JVM is throwing VerifyError rather than the more specific LinkageError.)
