当前位置： 文江博客话题详情

出现 java.lang.VerifyError 的原因

发布于 2024-07-05 19:56:06 字数 2065 浏览 6 评论 0原文

我正在调查以下java.lang.VerifyError：

java.lang.VerifyError: (class: be/post/ehr/wfm/application/serviceorganization/report/DisplayReportServlet, method: getMonthData signature: (IILjava/util/Collection;Ljava/util/Collection;Ljava/util/HashMap;Ljava/util/Collection;Ljava/util/Locale;Lorg/apache/struts/util/MessageRe˜̴Mt̴MÚw€mçw€mp:”MŒŒ
                at java.lang.Class.getDeclaredConstructors0(Native Method)
                at java.lang.Class.privateGetDeclaredConstructors(Class.java:2357)
                at java.lang.Class.getConstructor0(Class.java:2671)

它在部署servlet 的jboss 服务器启动时发生。 它是用jdk-1.5.0_11编译的，我尝试用jdk-1.5.0_15重新编译它，但没有成功。 也就是说，编译运行正常，但部署时，出现 java.lang.VerifyError 。

当我更改方法名称并收到以下错误时：

java.lang.VerifyError: (class: be/post/ehr/wfm/application/serviceorganization/report/DisplayReportServlet, method: getMD signature: (IILjava/util/Collection;Lj    ava/util/Collection;Ljava/util/HashMap;Ljava/util/Collection;Ljava/util/Locale;Lorg/apache/struts/util/MessageResources ØÅN|ØÅNÚw€mçw€mX#ÖM|XÔM
            at java.lang.Class.getDeclaredConstructors0(Native Method)
            at java.lang.Class.privateGetDeclaredConstructors(Class.java:2357
            at java.lang.Class.getConstructor0(Class.java:2671)
            at java.lang.Class.newInstance0(Class.java:321)
            at java.lang.Class.newInstance(Class.java:303)

您可以看到显示了更多的方法签名。

实际的方法签名是：

  private PgasePdfTable getMonthData(int month, int year, Collection dayTypes,
                          Collection calendarDays,
                          HashMap bcSpecialDays,
                          Collection activityPeriods,
                          Locale locale, MessageResources resources) throws   Exception {

我已经尝试使用 javap 查看它，并且给出了应有的方法签名。

当我的其他同事检查代码、编译并部署它时，他们也遇到了同样的问题。 当构建服务器获取代码并将其部署到开发或测试环境 (HPUX) 上时，会发生相同的错误。 此外，运行 Ubuntu 的自动测试机在服务器启动期间也显示相同的错误。

应用程序的其余部分运行正常，只有一个 servlet 出现故障。 任何去哪里寻找的想法都会有帮助。

原文

I'm investigating the following java.lang.VerifyError:

java.lang.VerifyError: (class: be/post/ehr/wfm/application/serviceorganization/report/DisplayReportServlet, method: getMonthData signature: (IILjava/util/Collection;Ljava/util/Collection;Ljava/util/HashMap;Ljava/util/Collection;Ljava/util/Locale;Lorg/apache/struts/util/MessageRe˜̴Mt̴MÚw€mçw€mp:”MŒŒ
                at java.lang.Class.getDeclaredConstructors0(Native Method)
                at java.lang.Class.privateGetDeclaredConstructors(Class.java:2357)
                at java.lang.Class.getConstructor0(Class.java:2671)

It occurs when the jboss server in which the servlet is deployed is started.
It is compiled with jdk-1.5.0_11 and I tried to recompile it with jdk-1.5.0_15 without succes. That is the compilation runs fine but when deployed, the java.lang.VerifyError occurs.

When I changed the method name and got the following error:

java.lang.VerifyError: (class: be/post/ehr/wfm/application/serviceorganization/report/DisplayReportServlet, method: getMD signature: (IILjava/util/Collection;Lj    ava/util/Collection;Ljava/util/HashMap;Ljava/util/Collection;Ljava/util/Locale;Lorg/apache/struts/util/MessageResources ØÅN|ØÅNÚw€mçw€mX#ÖM|XÔM
            at java.lang.Class.getDeclaredConstructors0(Native Method)
            at java.lang.Class.privateGetDeclaredConstructors(Class.java:2357
            at java.lang.Class.getConstructor0(Class.java:2671)
            at java.lang.Class.newInstance0(Class.java:321)
            at java.lang.Class.newInstance(Class.java:303)

You can see that more of the method signature is shown.

The actual method signature is:

  private PgasePdfTable getMonthData(int month, int year, Collection dayTypes,
                          Collection calendarDays,
                          HashMap bcSpecialDays,
                          Collection activityPeriods,
                          Locale locale, MessageResources resources) throws   Exception {

I already tried looking at it with javap and that gives the method signature as it should be.

When my other colleagues check out the code, compile it and deploy it, they have the same problem. When the build server picks up the code and deploys it on development or testing environments (HPUX), the same error occurs. Also an automated testing machine running Ubuntu shows the same error during server startup.

The rest of the application runs okay, only that one servlet is out of order.
Any ideas where to look would be helpful.

如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论， 你可以免费 注册 一个本站的账号。

评论（27）

怪我鬧 2024-07-12 19:56:06

虽然 Kevin 提到的原因是正确的，但在转向其他内容之前我肯定会检查以下内容：

  1. 检查类路径中的 cglibs 。
  2. 检查我的类路径中的 hibernate 版本。

拥有上述任何一项的多个或冲突版本很可能会导致意外问题，例如所讨论的问题。

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

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

回复 原文
少女情怀诗 2024-07-12 19:56:06

在 Android Studio 3.6.1 中更新 Gradle 后，发布版本中的 API 19 发生崩溃。

存在 Glide 库错误。 解决方案是重写 proguard-rules.txt。

降级 Gradle 也可以（classpath 'com.android.tools.build:gradle:3.5.3'），但它是一个过时的解决方案，不要使用它。

After updating Gradle in Android Studio 3.6.1 crashes happened on API 19 in release build.

There was a Glide library error. Solution is to rewrite proguard-rules.txt.

Also downgrading Gradle works (classpath 'com.android.tools.build:gradle:3.5.3'), but it is an outdated solution, don't use it.

回复 原文
不语却知心 2024-07-12 19:56:06

java.lang.VerifyError 是最糟糕的。

如果您的方法的字节码大小超过 64kb 限制，您将收到此错误； 但你可能已经注意到了。

您是否 100% 确定该类不存在于应用程序其他位置的类路径中，也许存在于另一个 jar 中？

另外，从您的堆栈跟踪中，源文件的字符编码（utf-8？）是否正确？

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?

回复 原文
天荒地未老 2024-07-12 19:56:06

当您针对与运行时使用的库不同的库进行编译时，可能会出现 java.lang.VerifyError 错误。

例如，当我尝试运行针对 Xerces 1 编译的程序时，就发生了这种情况，但在类路径上发现了 Xerces 2。 所需的类（在 org.apache.* 命名空间中）是在运行时找到的，因此 ClassNotFoundException 是不是结果。 类和方法发生了更改，因此运行时找到的方法签名与编译时的方法签名不匹配。

通常，编译器会标记方法签名不匹配的问题。 加载类时，JVM 将再次验证字节码，并在字节码尝试执行不应允许的操作（例如调用返回 String 的方法）时抛出 VerifyError 。 code>，然后将该返回值存储在保存 List 的字段中。

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.

回复 原文
尤怨 2024-07-12 19:56:06

verifyError 意味着类文件包含语法正确但违反某些语义限制的字节码，例如跨越方法边界的跳转目标。

基本上，只有当存在编译器错误或类文件以其他方式损坏（例如，由于 RAM 故障或 HD 故障）时，才会发生VerifyError。

尝试使用不同的 JDK 版本并在不同的计算机上进行编译。

VerifyError means that the class file contains bytecode that is syntactically correct but violates some semantic restriction e.g. a jump target that crosses method boundaries.

Basically, a VerifyError can only occur when there is a compiler bug, or when the class file gets corrupted in some other way (e.g. through faulty RAM or a failing HD).

Try compiling with a different JDK version and on a different machine.

回复 原文
回眸一笑 2024-07-12 19:56:06

我通过使项目导入库来修复了 Android 上的此错误，如下所述 http://developer.android.com/tools/projects/projects-eclipse.html#SettingUpLibraryProject

以前，我只是引用该项目（而不是使其成为一个库），并且收到了这个奇怪的VerifyError。

希望它能帮助某人。

I fixed this error on Android by making the project I was importing a library, as described here http://developer.android.com/tools/projects/projects-eclipse.html#SettingUpLibraryProject

Previously, I was just referencing the project (not making it a library) and I was getting this strange VerifyError.

Hope it helps someone.

回复 原文
逆夏时光 2024-07-12 19:56:06

正如 Kevin Panko 所说，这主要是因为库的变化。
因此，在某些情况下，“清理”项目（目录）然后进行构建就可以解决问题。

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.

回复 原文
梓梦 2024-07-12 19:56:06

您可以尝试的一件事是使用 -Xverify:all ，它将在加载时验证字节码，并且有时在字节码无效时给出有用的错误消息。

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.

回复 原文
ゞ记忆︶ㄣ 2024-07-12 19:56:06

就我而言，我的 Android 项目依赖于另一个为 Java 7 编译的 Java 项目。当我将该 Java 项目的编译器合规级别更改为 6.0 后，java.lang.VerifyError 消失了。

后来我发现这是一个 Dalvik问题：https://groups.google.com/forum/? fromgroups#!topic/android-developers/sKsMTZ42pwE

In my case my Android project depends on another Java project compiled for Java 7. java.lang.VerifyError disappeared after I changed Compiler Compliance Level of that Java project to 6.0

Later I found out that this is a Dalvik issue: https://groups.google.com/forum/?fromgroups#!topic/android-developers/sKsMTZ42pwE

回复 原文
云淡风轻 2024-07-12 19:56:06

由于 pack200 损坏了类文件，我遇到了这个问题。 经过一番搜索，发现了这个 java bug。 基本上，设置 --effort=4 导致问题消失。

使用java 1.5.0_17（尽管它出现在我尝试过的java 1.5的每个变体中）。

I was getting this problem due to pack200 mangling a class file. A bit of searching turned this java bug up. Basically, setting --effort=4 caused the problem to go away.

Using java 1.5.0_17 (though it cropped up in every single variant of java 1.5 I tried it in).

回复 原文
情域 2024-07-12 19:56:06

修复了类似的 java.lang.VerifyError 问题

        catch (MagickException e)

我通过替换为

        catch (Exception e)

在库项目（我的项目具有依赖项）中定义的位置

。 之后，我得到了关于同一库中的类的 java.lang.NoClassDefFoundError （根据 https 修复） ://stackoverflow.com/a/9898820/755804）。

I have fixed a similar java.lang.VerifyError issue by replacing

        catch (MagickException e)

with

        catch (Exception e)

where MagickException was defined in a library project (on which my project has a dependency).

After that I have got a java.lang.NoClassDefFoundError about a class from the same library (fixed according to https://stackoverflow.com/a/9898820/755804 ).

回复 原文
与酒说心事 2024-07-12 19:56:06

当您尝试加载针对 Oracle JDK 编译的库时，在 Android 上可能会发生这种情况。

这是 Ning 异步 HTTP 客户端的问题。

This can happen on Android when you're trying to load a library that was compiled against Oracle's JDK.

Here is the problem for Ning Async HTTP client.

回复 原文
好久不见√ 2024-07-12 19:56:06

生成错误的最小示例

一种简单的可能性是使用Jasmin，或者使用二进制文件编辑器手动编辑字节码。

让我们创建没有 return 指令（由 Java 中的 return; 语句生成）的 void 方法，JVMS 认为这是非法的。

在 Jasmin 中我们可以这样写：

.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

所以实际上没有返回指令。

现在，如果我们尝试运行 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 编译器向 voidreturn > 我们的方法。 这就是为什么我们不需要向 main 方法添加 return 的原因。 您可以使用javap检查这一点。

JVMS

当您尝试运行 JVMS 7 Chapter 4.5

JVMS说，当Java加载一个文件时，它必须先运行一系列检查以查看该类文件是否正常运行它。

此类错误不会在 Java 代码的单个编译和运行周期中生成，因为 JVMS 7 4.10 说：

尽管 Java 编程语言的编译器必须只生成满足所有静态和结构约束的类文件 [...
]

因此，要查看最小失败示例，我们需要生成没有 javac 的源代码。

Minimal example that generates the error

One simple possibility is to use Jasmin, or to manually edit the bytecode with a binary file editor.

Lets create void method without a return instruction (generated by the return; statement in Java), which the JVMS says is illegal.

In Jasmin we could write:

.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

We then do javac Main.j and javap -v Main says that we have compiled:

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

so really there is no return instruction.

Now if we try to run java Main we get:

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)

This error can never happen in Java normally, since the Java compiler adds an implicit return to void methods for us. This is why we don't need to add a return to our main methods. You can check this with javap.

JVMS

VerifyError happens when you try to run certain types of illegal class file as specified by JVMS 7 chapter 4.5

The JVMS says that when Java loads a file, it must run a series of checks to see that the class file is OK before running it.

Such errors cannot be generated on a single compile and run cycle of Java code, because JVMS 7 4.10 says:

Even though a compiler for the Java programming language must only produce class files that satisfy all the static and structural constraints [...
]

So to see a minimal failure example, we will need to generate the source code without javac.

回复 原文
表情可笑 2024-07-12 19:56:06

就我而言，我必须删除此块：

compileOptions {
    sourceCompatibility JavaVersion.VERSION_1_7
    targetCompatibility JavaVersion.VERSION_1_7
}

它在 Fragment.showDialog() 方法调用附近显示错误。

In my case I had to remove this block:

compileOptions {
    sourceCompatibility JavaVersion.VERSION_1_7
    targetCompatibility JavaVersion.VERSION_1_7
}

It was showing error near Fragment.showDialog() method call.

回复 原文
梦幻的味道 2024-07-12 19:56:06

此页面可能会给您一些提示 -
http://www.zanthan.com/itymbi/archives/000337.html

该方法的主体中可能存在 javac 无法发现的细微错误。 除非您在此处发布整个方法，否则很难诊断。

您可以从声明尽可能多的变量开始...这将捕获 zanthan 网站上提到的错误，并且无论如何通常是一个很好的做法。

This page may give you some hints -
http://www.zanthan.com/itymbi/archives/000337.html

There may be a subtle bug in the body of that method that javac fails to spot. Difficult to diagnose unless you post the whole method here.

You could start by declaring as many variables as possible as final... that would have caught the bug mentioned on the zanthan site, and is often a good practice anyways.

回复 原文
安静被遗忘 2024-07-12 19:56:06

检查类路径上同一 jar 文件的多个版本。

例如，我的类路径中有 opennlp-tools-1.3.0.jar 和 opennlp-tools-1.5.3.jar 并收到此错误。 解决方案是删除 opennlp-tools-1.3.0.jar。

Check for multiple versions of the same jar file on your classpath.

For example, I had opennlp-tools-1.3.0.jar and opennlp-tools-1.5.3.jar on my classpath and got this error. The solution was to delete opennlp-tools-1.3.0.jar.

回复 原文
醉生梦死 2024-07-12 19:56:06

CGLIB 2.2 使用JRE> 6 可能会触发类似的错误，请参阅“我应该升级到 CGLIB 3.0 吗？” 以及 Spring SPR-9669 的一些评论。

当 JRE 6 上一切正常并且简单地切换到 JRE7 就会出现问题时，尤其如此。

CGLIB < 2.2 with JRE > 6 could trigger similar errors, see "Should I upgrade to CGLIB 3.0?" and some commentary at Spring SPR-9669.

This is especially true when everything works fine on JRE 6 and simply switching to JRE7 breaks things.

回复 原文
追风人 2024-07-12 19:56:06

就我而言，我的项目 A 依赖于另一个项目，比如 X（A 正在使用 X 中定义的一些类）。 因此，当我在 A 的构建路径中添加 X 作为参考项目时，出现此错误。 然而，当我删除 X 作为引用的项目并将 X 的 jar 作为库之一包含时，问题就解决了。

Well in my case, my project A had a dependency on another, say X(A was using some of the classes defined in X). So when I added X as a reference project in the build path of A , I got this error. However when I removed X as the referenced project and included X's jar as one of the libraries, the problem was solved.

回复 原文
待天淡蓝洁白时 2024-07-12 19:56:06

当您使用 Maven 导入大量模块时，也可能会发生这种情况。
将有两个或多个类具有完全相同的名称（相同的限定名称）。
该错误是由于编译时和运行时之间的解释差异造成的。

It could also happen when you have a lot of module imports with maven.
There will be two or more classes having exactly the same name ( same qualified name).
This error is resulting from difference of interpretation between compile time and runtime.

回复 原文
英雄似剑 2024-07-12 19:56:06

导致此错误的另一个原因可能是 AspectJ <= 1.6.11 与 JRE > 的组合。 6.

请参阅 Eclipse Bug 353467 和 Kieker 门票 307 了解详情。

当 JRE 6 上一切正常并且迁移到 JRE7 会出现问题时尤其如此。

Another reason for this error can be the combination of AspectJ <= 1.6.11 with JRE > 6.

See Eclipse Bug 353467 and Kieker ticket 307 for details.

This is especially true when everything works fine on JRE 6 and moving to JRE7 breaks things.

回复 原文
呆° 2024-07-12 19:56:06

如果您正在迁移到 java7 或使用 java7，那么通常会看到此错误。 我遇到了上述错误，并努力找出根本原因，我建议在运行应用程序时尝试添加 "-XX:-UseSplitVerifier" JVM 参数。

If you are migrating to java7 or using java7 then generally this error can be seen. I faced above errors and struggled a lot to find out the root cause, I would suggest to try adding "-XX:-UseSplitVerifier" JVM argument while running your application.

回复 原文
安穩 2024-07-12 19:56:06

就我而言，我收到以下堆栈跟踪的验证错误，

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)

我通过删除 commons-codec-1.3.jar 的类路径条目解决了该错误，该 jar 的版本与 Jasper 附带的版本不匹配。

In my case, I was getting verify error with below stack trace

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)

I got it resolved by removing classpath entry for commons-codec-1.3.jar, there was a mismatch in version of this jar with the one comes with Jasper.

回复 原文
枕头说它不想醒 2024-07-12 19:56:06

java.lang.VerifyError 意味着您编译的字节码引用了 Android 无法找到的内容。 即使我在两个设备中运行相同的版本，此 verifyError 仅向我发出 kitkat4.4 和较低版本，而不是上述版本。 当我使用旧版本的 jackson json 解析器时，它显示 java.lang.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，没有 核心库，然后它作品。 这意味着core的方法和其他内容已迁移到最新版本的Databind2.7。 这解决了我的问题。

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

java.lang.VerifyError means your compiled bytecode is referring to something that Android cannot find. This verifyError Issues me only with kitkat4.4 and lesser version not in above version of that even I ran the same build in both Devices. when I used jackson json parser of older version it shows java.lang.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.+'

Then I have changed the Dependancy to the latest version 2.2 to 2.7 without the core library, then it works. which means the Methods and other contents of core is migrated to the latest version of Databind2.7. This fix my Issues.

compile 'com.fasterxml.jackson.core:jackson-annotations:2.7.0-rc3'
compile 'com.fasterxml.jackson.core:jackson-databind:2.7.0-rc3'
回复 原文
记忆消瘦 2024-07-12 19:56:06

请删除所有无法使用的 jar 文件并尝试运行。 它对我有用，我添加了一个 jcommons jar 文件和另一个 jcommons.1.0.14 jar 文件，所以删除 jcommons 及其对我的工作

please remove any unusable jar file and try to run. and its work for me i added a jcommons jar file and also another jcommons.1.0.14 jar file so remove jcommons and its working for me

回复 原文
流云如水 2024-07-12 19:56:06

在文件上写入：

{Wildfly-home}\modules\system\layers\base\org\picketbox\main

接下来写入依赖项：

write on file:

{Wildfly-home}\modules\system\layers\base\org\picketbox\main

into dependencies next: <module name="sun.jdk"/>

回复 原文
云雾 2024-07-12 19:56:06

我在 Java 17 上使用 Groovy 2.4 时遇到此错误 - 升级到 Groovy 2.5 修复了该问题。

I got this error when using Groovy 2.4 on Java 17 - upgrading to Groovy 2.5 fixed the issue.

回复 原文
半﹌身腐败 2024-07-12 19:56:06

在我的 Compose Multiplatform 项目中，原因是 Proguard 7.4.2 及其优化。

因此，我通过将此行添加到我的 rules.pro 文件中禁用了 Proguard 优化：

-dontoptimize

请参阅相关的 Compose 多平台存储库中的 GitHub 问题。

In my Compose Multiplatform project, the reason was Proguard 7.4.2 and its optimization.

So, I disabled Proguard optimization by adding this line to my rules.pro file:

-dontoptimize

See the related GitHub issue in Compose Multiplatform repository.

回复 原文
~没有更多了~

关于作者

彩扇题诗

暂无简介

0 文章
0 评论
836 人气
发私信

相关话题

更多

热门标签

操作系统 程序设计 IT运维 Linux系统管理 JavaScript 服务器应用 solaris C/C++ PHP Shell BSD Vue.js aix Oracle Python HTML 系统管理 HTML5 CSS 前端
更多

推荐作者

留蓝

文章 0 评论 0

18790681156

文章 0 评论 0

zach7772

文章 0 评论 0

Wini

文章 0 评论 0

ayeshaaroy

文章 0 评论 0

初雪

文章 0 评论 0

更多

友情链接

文江博客
    我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站，即表示您同意使用 Cookies 和您的相关数据。
    原文