java - 导入导致 verifyError？ java

Question

我正在开展一个项目，我们希望在该项目中重用近期类似项目的代码。然而，这一次，我们希望将代码拆分到三个库中，以便在未来的项目中更容易使用，我们也将在这些项目中重复使用这些代码。

我将像在 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)

Answer 1

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

1. 编译步骤，当编译器被告知使用您的导入语句时，构建限定名称来解析您的符号。生成字节码后，它不包含任何导入语句，因为导入是源代码的东西，它们在运行时永远不存在。在字节码中，每个符号都用包名完全限定。
2. 运行时验证，此时 JVM validator 负责将方法调用与该方法的定义相匹配。这是 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 项目添加为依赖项(注意，Netbeans projects ，而不仅仅是 JAR 文件)，以便在更新库时，您的 webapp 部署脚本会自动获取修改并您没有在不同位置安装冲突的库。