Причины получения java.ленг.Исключение verifyerror

java.lang.VerifyError самые худшие.

вы получите эту ошибку, если размер байт-кода вашего метода превышает предел 64kb; но вы, вероятно, заметили бы это.

вы на 100% уверены, что этот класс не присутствует в пути к классам в другом месте вашего приложения, возможно, в другой банке?

кроме того, из вашего stacktrace, является кодировка символов исходного файла (utf-8? Это верно?

Как сказал Кевин Панко, это в основном из-за изменений в библиотеке. Поэтому в некоторых случаях" чистый " проект (каталог), за которым следует сборка, делает трюк.

я исправил эту ошибку на Android, сделав проект, который я импортировал библиотеку, как описано здесь http://developer.android.com/tools/projects/projects-eclipse.html#SettingUpLibraryProject

ранее я просто ссылался на проект (не делая его библиотекой), и я получал этот странный VerifyError.

надеюсь, это кому-то поможет.

одна вещь, которую вы можете попробовать, это использовать -Xverify:all который будет проверять байт-код при загрузке и иногда дает полезные сообщения об ошибках, если байт-код недействителен.

VerifyError означает, что файл класса содержит байт-код, который синтаксически корректен, но нарушает некоторые семантические ограничения, например цель перехода, которая пересекает границы метода.

в принципе, VerifyError может возникать только при наличии ошибки компилятора или при повреждении файла класса каким-либо другим способом (например, через неисправную ОЗУ или неисправный HD).

попробуйте выполнить компиляцию с другой версией JDK и на другом компьютере.

в моем случае мой проект Android зависит от другого проекта Java, скомпилированного для Java 7. java.lang.VerifyError исчез после того, как я изменил уровень соответствия компилятора этого проекта Java на 6.0

позже я узнал, что это проблема Dalvik: https://groups.google.com/forum/?fromgroups#!topic/android-developers/sKsMTZ42pwE

Я получал эту проблему из-за pack200, искажающего файл класса. Немного поисков оказалось это ошибка java вверх. В основном, установка --effort=4 вызвал проблему, чтобы уйти.

используя java 1.5.0_17 (хотя он появился в каждом варианте java 1.5, в котором я его пробовал).

я исправил аналогичную java.ленг.Проблема VerifyError путем замены

        catch (MagickException e)

С

        catch (Exception e)

здесь MagickException был определен в проекте библиотеки (от которого зависит мой проект).

после этого у меня есть java.lang.NoClassDefFoundError о классе из той же библиотеки (исправлено в соответствии с https://stackoverflow.com/a/9898820/755804).

Это может произойти на Android, когда вы пытаетесь загрузить библиотеку, которая была скомпилирована против JDK Oracle.

вот в чем проблема для клиента HTTP Ning Async.

в моем случае мне пришлось удалить этот блок:

compileOptions {
    sourceCompatibility JavaVersion.VERSION_1_7
    targetCompatibility JavaVersion.VERSION_1_7
}

Он показывал ошибку рядом Fragment.showDialog() вызов метода.

минимальный пример, который генерирует ошибку

одна простая возможность использовать Жасмин, или вручную редактировать байт-код с помощью редактора двоичных файлов.

позволяет создать void способ без return инструкция (порожденный return; заявление на Java), которое JVMS говорит, является незаконным.

в Жасмин мы могли бы написать:

.class public Main
.super java/lang/Object

.method public static main([Ljava/lang/String;)V
   aload_0 ; Just so that we won't get another verify error for empty code.
.end method

мы тогда делаем javac Main.j и javap -v Main говорит, что у нас есть составлено:

public static void main(java.lang.String[]);
  descriptor: ([Ljava/lang/String;)V
  flags: ACC_PUBLIC, ACC_STATIC
  Code:
    stack=1, locals=1, args_size=1
       0: aload_0

так неужели нет инструкции return.

теперь, если мы попытаемся запустить java Main получаем:

Error: A JNI error has occurred, please check your installation and try again
Exception in thread "main" java.lang.VerifyError: (class: NoReturn, method: main signature: ([Ljava/lang/String;)V) Falling off the end of the code
        at java.lang.Class.getDeclaredMethods0(Native Method)
        at java.lang.Class.privateGetDeclaredMethods(Class.java:2701)
        at java.lang.Class.privateGetMethodRecursive(Class.java:3048)
        at java.lang.Class.getMethod0(Class.java:3018)
        at java.lang.Class.getMethod(Class.java:1784)
        at sun.launcher.LauncherHelper.validateMainClass(LauncherHelper.java:544)
        at sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:526)

эта ошибка никогда не может произойти в Java нормально, так как компилятор Java добавляет неявный return до void способы для нас. Вот почему нам не нужно добавлять return нашим main методы. Вы можете проверить это с помощью javap.

виртуальные машины

VerifyError происходит, когда вы пытаетесь запустить некоторые типы файлов незаконных классов, указанные в JVMS 7 Глава 4.5

JVMS говорит, что когда Java загружает файл, он должен выполнить серию проверок, чтобы увидеть, что файл класса в порядке, прежде чем запускать его.

такие ошибки не могут быть сгенерированы на одном цикле компиляции и запуска кода Java, потому что JVMS 7 4.10 говорит:

хотя компилятор для языка программирования Java должен создавать только файлы классов которые удовлетворяют всем статическим и структурным ограничениям [... ]

поэтому, чтобы увидеть минимальный пример сбоя, нам нужно будет сгенерировать исходный код без javac.

эта страница может дать вам некоторые подсказки - http://www.zanthan.com/itymbi/archives/000337.html

в теле этого метода может быть тонкая ошибка, которую javac не может обнаружить. Трудно диагностировать, если вы не разместите весь метод здесь.

вы можете начать с объявления как можно больше переменных, как окончательный... это поймало бы ошибку, упомянутую на сайте zanthan, и часто является хорошей практикой в любом случае.

в моем случае мой проект A зависел от другого, скажем X (A использовал некоторые из классов, определенных в X). Поэтому, когда я добавил X в качестве ссылочного проекта в путь сборки A, я получил эту ошибку. Однако, когда я удалил X как ссылочный проект и включил jar X в качестве одной из библиотек, проблема была решена.

проверить несколько версий одного файла Jar в ваш classpath.

например, у меня был opennlp-tools-1.3.0.jar и opennlp-инструменты-1.5.3.jar на моем classpath и получил эту ошибку. Решением было удалить opennlp-tools-1.3.0.сосуд.

CGLIB 6 может вызвать аналогичные ошибки, см. " должен ли я перейти на CGLIB 3.0?" и некоторые комментарии по Весна SPR-9669.

Это особенно верно, когда все работает нормально на JRE 6 и просто переключается на jre7 ломает вещи.

другой причиной этой ошибки может быть комбинация AspectJ 6.

посмотреть Ошибка Затмения 353467 и билет Kieker 307 для сведения.

Это особенно верно, когда все работает нормально на JRE 6 и переход на JRE7 ломает вещи.

Это также может произойти, когда у вас есть много импорта модулей с maven. Там будет два или более классов, имеющих точно такое же имя ( то же имя). Эта ошибка является результатом разницы в интерпретации между временем компиляции и временем выполнения.

Если вы переходите на java7 или используете java7, то обычно эта ошибка может быть замечена. Я столкнулся с вышеуказанными ошибками и изо всех сил пытался выяснить первопричину, я бы предложил попробовать добавить "- XX: - UseSplitVerifier" аргумент JVM при запуске приложения.

хотя причина, упомянутая Кевином, верна, но я бы обязательно проверил ниже, прежде чем переходить к чему-то другому:

1. Регистрация cglibs в моем пути к классу.
2. Регистрация hibernate версии в моем пути к классу.

велики шансы, что наличие нескольких или конфликтующих версий любого из вышеперечисленных может вызвать неожиданные проблемы, такие как рассматриваемый.

java.ленг.VerifyError означает, что ваш скомпилированный байт-код ссылается на то, что Android не может найти. Этот verifyError выдает меня только с kitkat4.4 и менее версия не выше версия из этого даже я запустил ту же сборку в обоих устройствах. когда я использовал jackson JSON parser старой версии, он показывает java.ленг.исключение verifyerror

compile 'com.fasterxml.jackson.core:jackson-databind:2.2.+'
compile 'com.fasterxml.jackson.core:jackson-core:2.2.+'
compile 'com.fasterxml.jackson.core:jackson-annotations:2.2.+'

тогда я изменил зависимость на последняя версия 2.2 до 2.7 без ядро библиотека, то он работает. что означает методы и другое содержание базовый переносится в последнюю версию Databind2.7. Это исправить мои проблемы.

compile 'com.fasterxml.jackson.core:jackson-annotations:2.7.0-rc3'
compile 'com.fasterxml.jackson.core:jackson-databind:2.7.0-rc3'

пожалуйста, удалите любой непригодный файл jar и попробуйте запустить. и его работа для меня я добавил файл jcommons jar, а также еще один jcommons.1.0.14 jar-файл, поэтому удалите jcommons и его работу для меня

в моем случае я получал ошибку проверки с помощью ниже трассировки стека

jasperreports-server-cp-6.4.0-bin\buildomatic\build.xml:61: The following error occurred while executing this line:
TIB_js-jrs-cp_6.4.0_bin\jasperreports-server-cp-6.4.0-bin\buildomatic\bin\setup.xml:320: java.lang.VerifyError: (class: org/apache/commons/codec/binary/Base64OutputStream, method: <init> signature: (Ljava/io/OutputStream;ZI[B)V) Incompatible argument to function
    at com.jaspersoft.jasperserver.crypto.KeystoreManager.createKeystore(KeystoreManager.java:257)
    at com.jaspersoft.jasperserver.crypto.KeystoreManager.init(KeystoreManager.java:224)
    at com.jaspersoft.buildomatic.crypto.KeystoreTask.execute(KeystoreTask.java:64)
    at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:292)
    at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:498)
    at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
    at org.apache.tools.ant.Task.perform(Task.java:348)
    at org.apache.tools.ant.taskdefs.Sequential.execute(Sequential.java:68)
    at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:292)
    at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:498)
    at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
    at org.apache.tools.ant.Task.perform(Task.java:348)
    at org.apache.tools.ant.Target.execute(Target.java:435)
    at org.apache.tools.ant.helper.ProjectHelper2.parse(ProjectHelper2.java:169)
    at org.apache.tools.ant.taskdefs.ImportTask.importResource(ImportTask.java:222)
    at org.apache.tools.ant.taskdefs.ImportTask.execute(ImportTask.java:163)
    at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:292)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:498)
    at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
    at org.apache.tools.ant.Task.perform(Task.java:348)
    at org.apache.tools.ant.Target.execute(Target.java:435)
    at org.apache.tools.ant.helper.ProjectHelper2.parse(ProjectHelper2.java:180)
    at org.apache.tools.ant.ProjectHelper.configureProject(ProjectHelper.java:93)
    at org.apache.tools.ant.Main.runBuild(Main.java:826)
    at org.apache.tools.ant.Main.startAnt(Main.java:235)
    at org.apache.tools.ant.launch.Launcher.run(Launcher.java:280)
    at org.apache.tools.ant.launch.Launcher.main(Launcher.java:109)

Я решил это, удалив запись classpath для commons-codec-1.3.Джар, было несоответствие в версии этой банки с той, что поставляется с Джаспером.