Causes of getting a java.lang.VerifyError
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
.
WorkManager: java.lang.VerifyError: Verifier rejected class androidx.work.impl.OperationImpl
The solution was a tad weird, I admit.
My first step was to update the dependency versions for WorkManager as well as Coroutines to the latest versions (as stated in the question details). After that, I updated the provider<> tag in my AndroidManifest.xml file from this:
<provider
android:name="androidx.work.impl.WorkManagerInitializer"
android:authorities="${applicationId}.workmanager-init"
tools:node="remove" />
to this:
<provider
android:name="androidx.startup.InitializationProvider"
android:authorities="${applicationId}.androidx-startup"
android:exported="false"
tools:node="merge" />
After that, everything just worked fine. /p>
debugging a java.lang.VerifyError
What is the full stack trace? It should show that which class is calling that method. Probably the reason is that the code is being executed against a different version of the library that it was compiled against, and there is some incompatible change between those library versions (from the error message it appears to be a different method return type).
If that error is not about any library, but about your own code, then do a clean build. The compiler should produce a compile error about all things which may cause a verify error at runtime. Or if the source code is correct, it should rebuild all the class files correctly.
java.lang.VerifyError on method that worked a minute ago
A VerifyError
means the bytecode is invalid, which points to a compiler problem. I would try rebuilding everything in the hopes that it goes away, but otherwise you should file a bug. The bytecode is required to call the superclass constructor manually via invokenonvirtual superclass/<init>()V
, but you shouldn't need to add super();
in the source, the compiler should handle that
java.lang.VerifyError:Illegal type in constant pool
This is now solved, it was probably caused by bytecode size of one of my methods exceeded the 64kb limit. Causes of getting a java.lang.VerifyError
Java.lang.VerifyError
AUTHav.class
is corrupt (sometimes?). Obviously some method is declared to throw something that is not a subclass of Throwable. Usually this shouldn't happen because a Java compiler would detect that problem and report an error. But maybe the class file is modified/instrumented or even generated at runtime and this introduces the sporadic error. Or you have a naming conflict and the classloaded sporadically sees a diffenent, non-Throwable class instead of the intended one.
If AUTHav.class
is contained in some archive, you could have a look at the byte code (with javap
or a decompiler) and check if you find a method with a suspicious throws
argument.
So the byte code is obfuscated ... then it could be - and this is just a guess - that you have more than one version of the library inside your J2EE container. As the classes are obfuscated, there is a chance that the class names AUTHa7
and/or AUTHa1
are used for different (orginal) classes in different versions of the library. And then, if the classloader picks up both or maybe the wrong one at the wrong time, it could happen, that AUTHa7
and/or AUTHa1
are not Exceptions at runtime...
Related Topics
Android: Launch Activity from Clickable Text
How to Get Each Device's Ip Address in Wi-Fi Direct Scenario
Proguard Missing Type Parameter
Bitmap, Bitmap.Recycle(), Weakreferences, and Garbage Collection
How to Set Minimum Datepicker Date to Current Date
How to Send Notification to Specific Users with Fcm
How to Change the Background Color Around a Dialogfragment
Get My Phone Number in Android
Gridview with Different Cells Sizes, Pinterest Style
Remove Bottomnavigationview Labels
Disable the Touch Events for All the Views
Android Studio 2.0 - Pause/White Screen on App First Run
Android: Rotate Image Without Loading It to Memory
Immersive Mode Navigation Becomes Sticky After Volume Press or Minimise-Restore
Google Cloud Messaging - Messages Sometimes Not Received Until Network State Changed