java.lang.VerifyError
can be the result when you have compiled against a different library than you are using at runtime.
For example, this happened to me when trying to run a program that was compiled against Xerces 1, but Xerces 2 was found on the classpath. The required classes (in org.apache.*
namespace) were found at runtime, so ClassNotFoundException
was not the result. There had been changes to the classes and methods, so that the method signatures found at runtime did not match what was there at compile-time.
Normally, the compiler will flag problems where method signatures do not match. The JVM will verify the bytecode again when the class is loaded, and throws VerifyError
when the bytecode is trying to do something that should not be allowed -- e.g. calling a method that returns String
and then stores that return value in a field that holds a List
.
java.lang.VerifyError
are the worst.
You would get this error if the bytecode size of your method exceeds the 64kb limit; but you would probably have noticed that.
Are you 100% sure this class isn't present in the classpath elsewhere in your application, maybe in another jar?
Also, from your stacktrace, is the character encoding of the source file (utf-8
?) Is that correct?
As Kevin Panko said, it's mostly because of library change. So in some cases a "clean" of the project (directory) followed by a build does the trick.
One thing you might try is using -Xverify:all
which will verify bytecode on load and sometimes gives helpful error messages if the bytecode is invalid.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With