JDeps是Java依赖关系分析工具 ，这是一个命令行工具，它处理Java字节码（意味着.class文件或包含它们的JAR），并分析类之间静态声明的依赖关系。 可以用各种方式过滤结果，并可以将其汇总到包或JAR级别。 JDeps还可以告诉您您的项目使用了哪些JDK内部API，并且完全了解模块系统 。 总而言之，它是检查各种形式的依赖图的非常有用的工具。

在这篇文章中，我将向您介绍JDeps的工作方式-后续文章将向您展示一些很好的用例。 对于此探索，我鼓励您继续进行，最好是执行您的一个项目。 如果您有一个项目的JAR，并且在它旁边有一个包含所有传递依赖项的文件夹，这将是最容易的。 如果您使用的是Maven，则可以通过maven-dependency-plugin的copy-dependencies目标实现后者。 使用Gradle，您可以使用复制任务，从设置为configuration.compile或configuration.runtime 。

作为示例项目，我选择了Scaffold Hunter ：

Scaffold Hunter是基于Java的开源工具，用于对数据集进行可视化分析，重点是生命科学中的数据，旨在直观地访问大型和复杂的数据集。 该工具提供多种视图，例如图形，树状图和图解视图，以及分析方法，例如用于聚类和分类

我下载了2.6.3版本的ZIP，并将所有依赖项都复制到了libs中。

当显示输出时，我将scaffoldhunter（在软件包名称中）和scaffold-hunter（在文件名称中）缩写为sh以使其更短。

认识JDeps

从Java 8开始，您就可以在JDK的bin文件夹中找到JDeps可执行文件jdeps。如果在命令行上可以找到JDeps可执行文件jdeps，则最容易使用它，为此您可能必须执行一些特定于操作系统的设置步骤。 确保jdeps –version可以正常工作并显示Java 9版本正在运行。

下一步是获取JAR并将JDeps设置为宽松。 在不使用其他命令行选项的情况下使用，它将首先列出代码所依赖的JDK模块。 紧随其后的是软件包级别的依赖关系列表，其组织为<package>-> <package> <module / JAR>。

调用jdeps sh-2.6.3.jar将产生以下输出：

$ jdeps sh-2.6.3.jarsh-2.6.3.jar -> java.base
sh-2.6.3.jar -> java.datatransfer
sh-2.6.3.jar -> java.desktop
sh-2.6.3.jar -> java.logging
sh-2.6.3.jar -> java.prefs
sh-2.6.3.jar -> java.sql
sh-2.6.3.jar -> java.xml
sh-2.6.3.jar -> not foundedu.udo.sh -> com.beust.jcommander  not foundedu.udo.sh -> edu.udo.sh.data       sh-2.6.3.jaredu.udo.sh -> edu.udo.sh.gui        sh-2.6.3.jaredu.udo.sh -> edu.udo.sh.gui.util   sh-2.6.3.jaredu.udo.sh -> edu.udo.sh.util       sh-2.6.3.jaredu.udo.sh -> java.io               java.baseedu.udo.sh -> java.lang             java.baseedu.udo.sh -> javax.swing           java.desktopedu.udo.sh -> org.slf4j             not found
[... truncated many more package dependencies ...]

您可以看到Scaffold Hunter依赖于模块java.base （当然）， java.desktop （这是一个Swing应用程序）， java.sql （数据集存储在SQL数据库中）以及其他一些模块。 这之后是一堆长长的软件包依赖项，这有点麻烦。请注意，有些依赖项被标记为未找到，这很有意义，因为我没有告诉JDeps在哪里寻找它们。

现在是时候使用各种选项配置JDeps了。 您可以使用jdeps -h列出它们。

包括依赖项

JDeps的一个重要方面是，它使您可以像分析代码一样将其依赖性进行分析。 该目标的第一步是使用–class-path将它们放到类路径中。

这使JDeps能够遵循进入依赖项JAR的路径，并使您摆脱未找到的指标。 要实际分析依赖关系，还需要使用-recursive或-R将JDeps递归到它们。

为了包括Scaffold Hunter的依赖关系，我使用–class-path'libs / *'和-recursive执行JDeps：

$ jdeps --class-path 'libs/*' -recursive sh-2.6.3.jar[... truncated split package warnings ...]
[... truncated some module/JAR dependencies...]
sh-2.6.3.jar -> libs/commons-codec-1.6.jar
sh-2.6.3.jar -> libs/commons-io-2.4.jar
sh-2.6.3.jar -> libs/dom4j-1.6.1.jar
sh-2.6.3.jar -> libs/exp4j-0.1.38.jar
sh-2.6.3.jar -> libs/guava-18.0.jar
sh-2.6.3.jar -> libs/heaps-2.0.jar
sh-2.6.3.jar -> libs/hibernate-core-4.3.6.Final.jar
sh-2.6.3.jar -> java.base
sh-2.6.3.jar -> java.datatransfer
sh-2.6.3.jar -> java.desktop
sh-2.6.3.jar -> java.logging
sh-2.6.3.jar -> java.prefs
sh-2.6.3.jar -> java.sql
sh-2.6.3.jar -> java.xml
sh-2.6.3.jar -> libs/javassist-3.18.1-GA.jar
sh-2.6.3.jar -> libs/jcommander-1.35.jar
[... truncated more module/JAR dependencies...]edu.udo.sh -> com.beust.jcommander  jcommander-1.35.jaredu.udo.sh -> edu.udo.sh.data       sh-2.6.3.jaredu.udo.sh -> edu.udo.sh.gui        sh-2.6.3.jaredu.udo.sh -> edu.udo.sh.gui.util   sh-2.6.3.jaredu.udo.sh -> edu.udo.sh.util       sh-2.6.3.jaredu.udo.sh -> java.io               java.baseedu.udo.sh -> java.lang             java.baseedu.udo.sh -> javax.swing           java.desktopedu.udo.sh -> org.slf4j             slf4j-api-1.7.5.jar
[... truncated many, many more package dependencies ...]

在这种特定情况下，输出以一些拆分程序包警告开头，我现在将忽略它们。 以下模块/ JAR和程序包的依赖关系与以前类似，但是现在都可以找到，因此它们的数量更多。 但是，这会使输出变得更加压倒一切，因此现在该是时候来研究如何从如此大量的数据中弄清楚了。

配置JDeps的输出

有多种方法可以配置JDeps的输出。 也许在任何项目的首次分析中使用的最佳选择是-summary或​​-s，它们仅显示JAR之间的依赖关系，而忽略包的依赖关系。 下表列出了各种其他方式来获取有关依赖关系的不同观点：

选项	描述
–package或-p	其次是只考虑在该包，这是看哪里使用这些utils的所有地方一个伟大的方式依赖包名。
–regex或-e	后跟一个正则表达式，它仅考虑对与正则表达式匹配的类的依赖。 （请注意，除非使用-verbose：class，否则输出仍会显示包。）
-filter或-f	后跟一个正则表达式，它排除对与正则表达式匹配的类的依赖。 （请注意，除非使用-verbose：class，否则输出仍会显示包。）
-filter：存档	在许多情况下，工件内的依赖性不是那么有趣。 此选项将忽略它们，仅显示跨工件的依赖性。
–仅API	有时，尤其是在分析库时，您只关心JAR API。 使用此选项，仅检查公共签名和公共类的受保护成员的签名中提到的类型。

命令行上的输出是检查细节并深入研究有趣的位的好方法。 但是，它并不能提供最直观的概述-图表要好得多。 幸运的是，JDeps具有–dot-output选项，该选项可为每个单独的分析创建.dot文件 。 这些文件是纯文本，但是可以使用其他工具（例如Graphviz）从它们创建图像。

这两个命令产生下图：

$ jdeps --class-path 'libs/*' -recursive --dot-output dots sh-2.6.3.jar
$ dot -Tpng -O dots/summary.dot

深钻

如果您想了解更多细节，-verbose：class将列出类之间的依赖关系，而不是将它们聚合到包级别。

有时，仅列出对程序包或类的直接依赖是不够的，因为它们可能实际上不在代码中，而在依赖中。 在这种情况下，-inverse或-I可能会有所帮助。 给定要查找的特定程序包或正则表达式，它会一直跟踪依赖关系，并在此过程中列出工件。 不幸的是，似乎没有直接方法可以在类级别而不是工件上查看结果。

在您的特定情况下，还有其他一些选项可能会对您有所帮助–如前所述，您可以使用jdeps -h列出它们。

JDeps和模块

就像由于模块系统 ，编译器和JVM可以在更高的抽象级别上运行一样 ，JDeps也可以。 可以使用–module-path指定模块路径（请注意-p已经保留，因此它不是此选项的简写），而初始模块可以使用–module或-m指定。 从那里，我们上面所做的分析可以完全相同。

因为Scaffold Hunter尚未模块化，所以我将切换到我在书中使用的有关Java 9模块系统的示例项目Monitor应用程序 。 在这里，我正在创建模块关系的摘要分析：

# on `master` branch
$ jdeps --module-path mods:libs -m monitor -summary -recursive[... truncated some module dependencies...]
monitor -> java.base
monitor -> monitor.observer
monitor -> monitor.observer.alpha
monitor -> monitor.observer.beta
monitor -> monitor.persistence
monitor -> monitor.rest
monitor -> monitor.statistics
monitor.observer -> java.base
monitor.observer.alpha -> java.base
monitor.observer.alpha -> monitor.observer
monitor.observer.beta -> java.base
monitor.observer.beta -> monitor.observer
monitor.persistence -> java.base
monitor.persistence -> monitor.statistics
monitor.rest -> java.base
monitor.rest -> monitor.statistics
monitor.rest -> spark.core
monitor.statistics -> java.base
monitor.statistics -> monitor.observer
slf4j.api -> java.base
slf4j.api -> not found
spark.core -> JDK removed internal API
spark.core -> java.base
spark.core -> javax.servlet.api
spark.core -> jetty.server
spark.core -> jetty.servlet
spark.core -> jetty.util
spark.core -> slf4j.api
spark.core -> websocket.api
spark.core -> websocket.server
spark.core -> websocket.servlet
[... truncated more module dependencies...]

除此之外，还有一些Java 9和特定于模块的选项。 使用–require <modules>，您可以列出所有需要命名模块的模块。 您可以使用–jdk-internals分析项目的有问题的依赖关系，以及–generate-module-info或–generate-open-module创建模块描述符的初稿。 正如前面提到的，JDeps还将始终报告其找到的所有拆分包。

在以后的文章中，我将向您展示如何使用这些标志来帮助您的项目进行模块化。

获取我的书，并了解有关如何在Java 9迁移中使用JDeps的更多信息！
Java 9模块系统

• 模块系统的深入介绍：
  • 基本概念和高级主题
• 曼宁（Manning）发布：
  • 自2017年赛事开始提供抢先体验
• 订阅我的时事通讯以保持关注。
  （甚至可以偷看。）

使用代码fccparlog可获得 37％的折扣 ！

反射

使用JDeps，您可以分析项目的静态声明的依赖关系。 它在类级别上运行，但是将结果汇总到包和工件级别。 使用各种过滤器，您可以专注于最重要的方面。 也许最基本的分析是跨代码和第三方库的工件依赖关系图：

$ jdeps --class-path 'libs/*' -summary -recursive sh-2.6.3.jar

它可用于执行一些非常有趣的分析，尤其是在较大的代码库上。 我将很快向您展示一些示例。

翻译自: https://www.javacodegeeks.com/2017/07/jdeps-primer-analyzing-projects-dependencies.html