【问题标题】:Imports causing verifyError? java导入导致验证错误?爪哇
【发布时间】:2012-12-26 14:08:12
【问题描述】:

我正在开展一个项目,我们希望在该项目中重复使用最近类似项目的代码。但是,这一次,我们希望将代码拆分为三个库,以便在我们将重用此代码的未来项目中更容易使用。

我将像在 Netbeans 中一样描述项目设置。

之前,我有一个 Java Web 应用程序项目,其中包含许多源代码包和一堆库。

现在,我们已将源代码包分发到三个 Java 应用程序项目中。我们需要第四个 Java Web 应用程序项目,我们将这三个项目作为库导入,我们可以测试代码中实现的 RESTful Web 服务。

问题在于,为了在重构后使所有导入工作,我们最终将原始项目中的所有库都包含在所有四个新项目中。我们很确定这会导致 java.lang.VerifyError 导致我们几天都无法解决。

将主项目重构为3部分后,它们相互包含如下(它们还包括原始项目中使用的每个库):

A (A imports B and C)
|
B (B imports C)
|
C 

Web 应用程序项目导入所有内容:三个源代码项目以及主项目中使用的所有库。如果我们不包括它们,当我们尝试测试 RESTful Web 服务时,我们将看不到左侧的资源。

问题是是否有任何关于如何组织库的建议,以便我们停止收到此 VerifyError(如果这是它发生的原因)

ERROR MESSAGE: 
Exception in thread "main" java.lang.VerifyError: (class: com/couchbase/client/CouchbaseClient, method: asyncQueryAndReduce signature: (Lcom/couchbase/client/protocol/views/View;Lcom/couchbase/client/protocol/views/Query;)Lcom/couchbase/client/internal/HttpFuture;) Incompatible argument to function

我在测试一个创建了 couchbase 客户端的简单类时收到了该错误消息。当我们测试真正的 Web 服务时,我们会得到相同的错误,但堆栈跟踪更大更复杂,但基本上是相同的错误。

FULL ERROR WHEN WE RUN THE WEB SERVICE:
java.lang.VerifyError: (class: com/couchbase/client/CouchbaseClient, method: asyncGetView signature: (Ljava/lang/String;Ljava/lang/String;)Lcom/couchbase/client/internal/HttpFuture;) Incompatible argument to function
at models.cache.utils.PoolableCouchbaseClientObjectFactory.makeObject(PoolableCouchbaseClientObjectFactory.java:53)
at models.cache.utils.PoolableCouchbaseClientObjectFactory.makeObject(PoolableCouchbaseClientObjectFactory.java:24)
at org.apache.commons.pool.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:1188)
at models.cache.utils.CouchbaseConnector.connectCache(CouchbaseConnector.java:48)
at models.cache.controllers.SessionCacheHandler.setUserSession(SessionCacheHandler.java:65)
at services.handlers.LoginPOSTHandler.run(LoginPOSTHandler.java:296)
at services.LoginResource.post(LoginResource.java:128)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at com.sun.jersey.server.impl.model.method.dispatch.AbstractResourceMethodDispatchProvider$ResponseOutInvoker._dispatch(AbstractResourceMethodDispatchProvider.java:168)
at com.sun.jersey.server.impl.model.method.dispatch.ResourceJavaMethodDispatcher.dispatch(ResourceJavaMethodDispatcher.java:67)
at com.sun.jersey.server.impl.uri.rules.HttpMethodRule.accept(HttpMethodRule.java:259)
at com.sun.jersey.server.impl.uri.rules.ResourceClassRule.accept(ResourceClassRule.java:83)
at com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:133)
at com.sun.jersey.server.impl.uri.rules.RootResourceClassesRule.accept(RootResourceClassesRule.java:71)
at com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:990)
at com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:941)
at com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:932)
at com.sun.jersey.spi.container.servlet.WebComponent.service(WebComponent.java:384)
at com.sun.jersey.spi.container.servlet.ServletContainer.service(ServletContainer.java:451)
at com.sun.jersey.spi.container.servlet.ServletContainer.service(ServletContainer.java:632)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:722)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
at org.netbeans.modules.web.monitor.server.MonitorFilter.doFilter(MonitorFilter.java:393)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:225)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:169)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:168)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:98)
at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:927)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407)
at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:999)
at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:565)
at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:307)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:722)

【问题讨论】:

  • 你能添加VerifyError的确切错误信息吗?
  • 发布确切的错误消息和堆栈跟踪,以及导致它的代码。我认为您只是在做出错误的假设。 VerifyError 与导入没有任何关系。
  • 我贴出来了。有任何想法吗?我认为这是因为导入,因为失败的是在重构之前没有失败的 couchbase 方法
  • 您运行的 CouchDB 版本似乎与您编译的版本不同
  • 也许 问题 位于 PoolableCouchbaseClientObjectFactory 的第 53 行。也粘贴该行。请注意,如果我没记错的话,Netbeans 具有可以打包不可编译代码的危险特性

标签: java import verifyerror


【解决方案1】:

Java是一种编译语言,所以有两个时刻:

  1. 编译步骤,当告诉编译器使用您的导入语句时,构建限定名称以解析您的符号。一旦生成了字节码,它就不包含任何导入语句,因为导入是源代码的东西,它们在运行时永远不存在。在字节码中,每个符号都使用包名完全限定。
  2. 运行时验证,当 JVM 验证器负责将方法调用与该方法的定义进行匹配时。这是 VerifyError 被抛出的时候

这意味着有两个不同的代理对加载定义感兴趣:编译器和 JVM。两者都可以从 CLASSPATH 加载类定义,但在运行时,例如,您的 webapp 类加载器也可以从 WEB-INF/lib 目录加载类。

在开发库时,您可以将存档添加到构建路径(或者您可以使用 Apache Ivy 或 Maven 等依赖项管理工具),但您不应在构建过程的输出中打包依赖项。由用户提供所需的库。

因此,例如您开发 A 并将 B 和 C 项目添加到构建路径中,因此编译器可以解析符号并愉快地编译所有内容,但最终的 JAR 必须只包含项目 A 的类。对于 B 也是如此, 显然对于 C.

当你开发你的 web 应用程序时,你的构建路径中会包含 A、B、C,但你还应该注意设置一个构建过程,在部署之前复制 WEB-INF/lib 中的所有内容,否则你会在运行时遇到缺少库的情况。

正如我之前所说,您可以使用 Maven 组织您的项目,或者您可以使用 Ivy 管理依赖项,或者您可以简单地使用专有的 Netbeans 项目,如果 Netbeans 是您团队中的标准并且您不想采用其他技术。如果选择 Netbeans 方式,则应将 Netbeans 项目添加为依赖项(NB,Netbeans projects ,而不仅仅是 JAR 文件),以便在更新库时,您的 webapp 部署脚本会自动抓取修改并您没有在不同的地方安装有冲突的库。

【讨论】:

  • 我的三个新项目都需要或多或少相同的库。有没有办法只将它们包含在项目 C 中,然后 B 和 A 在导入 C 时获取它们?
  • 请不要使用术语import,它具有误导性,因为它是使编译器解析符号的有效Java 指令。如果您的意思是在 C 中打包所需的 JAR,以便它们自动可用于所有需要 C 的项目,那么是的,有,但这是不好的做法,可能会破坏事情。您最好使用具有 transitive 依赖概念并为您管理一切的依赖框架。 Maven 和 Ivy 肯定可以做到,我不知道 Netbeans 是否管理传递的 deps,但你真的应该寻找 Maven,因为它是事实上的 Java 标准
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2020-03-08
  • 2013-02-04
  • 1970-01-01
  • 1970-01-01
  • 2023-03-28
相关资源
最近更新 更多