一个类加载的谜团解决了

面对一个好老问题

我在应用程序服务器上遇到一些类加载问题。这些库被定义为Maven依赖项，因此被打包到WAR和EAR文件中。不幸的是，其中一些也已安装到应用程序服务器中，但版本不同。启动应用程序时，我们遇到了与这些类型的问题相关的各种异常。如果您想深入了解，那么有一篇不错的IBM文章关于这些异常。

即使我们知道该错误是由类路径上的某些双重定义的库引起的，但仍花了两个多小时来调查我们真正需要的版本以及要删除的JAR。

同一周在水罐上偶然发生了相同的话题

几天后，我们参加了“您真的得到了Classloaders吗？苏黎世Java用户协会会议。 Simon Maple对类加载器进行了非常出色的介绍，并从一开始就介绍了非常深入的细节。对于许多人来说，这是一次令人大开眼界的会议。我还必须注意，Simon工作零周转，他为JRebel进行宣传。在这种情况下，辅导课程通常偏向于实际产品，即辅导员的面包。在这种情况下，我认为西蒙绝对是绅士和道德主义者，保持了适当的平衡。

创建一个工具，解决神秘问题

只是创造另一个

一周后，我花了一些时间来学习程序，而现在我已经有几个星期没有时间了，所以我决定创建一个小工具，列出所有在类路径中的类和JAR文件，以便可以更轻松地查找重复。我试图依靠这样的事实，即类加载器通常是URLClassLoader实例，因此可以调用方法getURLs()来获取所有目录名称和JAR文件。

在这种情况下，单元测试可能非常棘手，因为该功能与类加载器的行为密切相关。为了务实，我决定只做一些从JUnit开始的手动测试，只要代码是实验性的即可。首先，我想看看这个概念是否值得进一步发展。我打算执行测试，并查看报告没有重复类的日志语句，然后执行相同的运行，但是第二次向类路径添加一些冗余依赖项。我使用的是JUnit 4.10，在这种情况下，该版本很重要。

我从命令行执行了单元测试，发现没有重复的类，我感到很高兴。之后，我从Eclipse执行了相同的测试，并且感到惊讶：我冗余定义了21个类！

12:41:51.670 DEBUG c.j.c.ClassCollector - There are 21 redundantly defined classes.
12:41:51.670 DEBUG c.j.c.ClassCollector - Class org/hamcrest/internal/SelfDescribingValue.class is defined 2 times:
12:41:51.671 DEBUG c.j.c.ClassCollector -   sun.misc.Launcher$AppClassLoader@7ea987ac:file:/Users/verhasp/.m2/repository/junit/junit/4.10/junit-4.10.jar
12:41:51.671 DEBUG c.j.c.ClassCollector -   sun.misc.Launcher$AppClassLoader@7ea987ac:file:/Users/verhasp/.m2/repository/org/hamcrest/hamcrest-core/1.1/hamcrest-core-1.1.jar
...

仔细研究一下，我很容易发现JUnit 4.10具有额外的依赖关系，如maven所示。

$ mvn dependency:tree
[INFO] Scanning for projects...
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Building clalotils 1.0.0-SNAPSHOT
[INFO] ------------------------------------------------------------------------
[INFO]
[INFO] --- maven-dependency-plugin:2.8:tree (default-cli) @ clalotils ---
[INFO] com.verhas:clalotils:jar:1.0.0-SNAPSHOT
[INFO] +- junit:junit:jar:4.10:test
[INFO] |  \- org.hamcrest:hamcrest-core:jar:1.1:test
[INFO] +- org.slf4j:slf4j-api:jar:1.7.7:compile
[INFO] \- ch.qos.logback:logback-classic:jar:1.1.2:compile
[INFO]    \- ch.qos.logback:logback-core:jar:1.1.2:compile
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 2.642s
[INFO] Finished at: Wed Sep 03 12:44:18 CEST 2014
[INFO] Final Memory: 13M/220M
[INFO] ------------------------------------------------------------------------

这实际上在4.11中已修复，因此如果我将依赖关系更改为JUnit 4.11，则不会遇到此问题。好。一半的谜团解决了。但是，为什么maven命令行执行未报告双重定义的类？

扩展日志记录，越来越多的日志记录我可以发现一条线：

12:46:19.433 DEBUG c.j.c.ClassCollector - Loading from the jar file /Users/verhasp/github/clalotils/target/surefire/surefirebooter235846110768631567.jar

这个文件里有什么？让我们解压缩它：

$ ls -l /Users/verhasp/github/clalotils/target/surefire/surefirebooter235846110768631567.jar
ls: /Users/verhasp/github/clalotils/target/surefire/surefirebooter235846110768631567.jar: No such file or directory

该文件不会退出！看来maven创建了这个JAR文件，然后在测试执行完成后将其删除。再次使用Google搜索，找到了解决方案。

Java从类路径加载类。可以在命令行上定义类路径，但是应用程序类加载器还有其他来源可以从中获取文件。一个这样的源是JAR的清单文件。 JAR文件的清单文件可以定义执行JAR文件中的类所需的其他JAR文件。 Maven创建一个JAR文件，除了清单文件定义清单中列出JAR和列出类路径的目录外，该文件不包含其他内容。这些JAR和目录不是通过getURLs()方法返回的，因此我的小工具（第一个版本）没有找到重复项。

出于演示目的，我已经足够快地在运行mvn test命令的同时复制了文件，并获得了以下输出：

$ unzip /Users/verhasp/github/clalotils/target/surefire/surefirebooter5550254534465369201\ copy.jar
Archive:  /Users/verhasp/github/clalotils/target/surefire/surefirebooter5550254534465369201 copy.jarinflating: META-INF/MANIFEST.MF
$ cat META-INF/MANIFEST.MF
Manifest-Version: 1.0
Class-Path: file:/Users/verhasp/.m2/repository/org/apache/maven/surefire/surefire-booter/2.8/surefire-booter-2.8.jar file:/Users/verhasp/.m2/repository/org/apache/maven/surefire/surefire-api/2.8/surefire-api-2.8.jar file:/Users/verhasp/github/clalotils/target/test-classes/ file:/Users/verhasp/github/clalotils/target/classes/ file:/Users/verhasp/.m2/repository/junit/junit/4.10/junit-4.10.jar file:/Users/verhasp/.m2/repository/org/hamcrest/hamcrest-core/1.1/hamcrest-core-1.1.jar file:/Users/verhasp/.m2/repository/org/slf4j/slf4j-api/1.7.7/slf4j-api-1.7.7.jar file:/Users/verhasp/.m2/repository/ch/qos/logback/logback-classic/1.1.2/logback-classic-1.1.2.jar file:/Users/verhasp/.m2/repository/ch/qos/logback/logback-core/1.1.2/logback-core-1.1.2.jar
Main-Class: org.apache.maven.surefire.booter.ForkedBooter$

实际上，除了定义类路径的清单文件外，别无其他。但是为什么Maven会这样做呢？索纳型的人，我个人也认识一些聪明的人。他们不会无所事事地做这种事情。创建临时JAR文件以启动测试的原因是，在某些类路径长度可能超过的操作系统上，命令行的长度受到限制。即使Java（自Java 6起）本身可以解析类路径中的通配符，也不是maven的选择。 JAR文件位于Maven存储库中的不同目录中，每个目录都具有长名称。通配符解析不是递归的，这是有充分理由的，即使是通配符解析，您也不希望将所有本地存储都放在类路径中。

结论

不要使用JUnit 4.10！使用旧的或较新的东西，或为意外做好准备。
了解什么是类加载器以及它如何工作，做什么。
使用对命令行长度的最大大小有巨大限制的操作系统。
或只是忍受限制。

还有吗你的想法？

翻译自: https://www.javacodegeeks.com/2014/09/a-classloading-mystery-solved.html