guava listenablefuture版本号9999.0-empty-to-avoid-conflict-with-guava的原因

最新推荐文章于 2024-08-25 09:40:23 发布

花落的速度

最新推荐文章于 2024-08-25 09:40:23 发布

阅读量4.5k

点赞数

分类专栏： Java 文章标签： guava maven gradle

本文链接：https://blog.csdn.net/q2878948/article/details/110038191

版权

Java 专栏收录该内容

22 篇文章 0 订阅

订阅专栏

检查源码时偶然发现有个版本号9999的jar包依赖：listenablefuture-9999.0-empty-to-avoid-conflict-with-guava.jar ，很好奇为什么搞个这样的版本号。

从maven的依赖管理说起

网上谈maven依赖管理的文章很多了，有兴趣详细了解可以自行百度一下。当有依赖传递过程中不同的parent使用了相同的子依赖时：

A依赖于B及C，而B又依赖于X、Y，而C依赖于D、M，D依赖于X、N则A除引B及C的依赖包下，还会引入D、X，Y，M，N的依赖包（一般情况下了，Maven可通过<scope>等若干种方式控制传递依赖）。

这里有一个需要特别注意的，假设B依赖于X的1.0版本，而D依赖于X的2.0版本，A究竟依赖于X的1.0还是2.0版本呢？

maven的原则是：

显示声明级别最高。如果版本号在parent的pom文件中显式声明过，明确指明我需要哪个版本，那么在之后声明的相同jar包版本都会被忽略。
最短路径优先。A->B->X三层，A->C->D->X四层，这时候A中使用的X版本为B中声明的1.0版。

这时候如果我们既不想在A中显式指定子依赖X的版本，又想用D的2.0版，那么可以考虑使用exclusions标签将C中的X依赖排除出去：

<dependency>
<groupId>com.example</groupId>
<artifactId>A</artifactId>
<version>0.0.1</version>
<exclusions>
<exclusion>
<groupId>com.example</groupId>
<artifactId>X</artifactId>
</exclusion>
</exclusions>
</dependency>

回到guava:listenablefuture的9999.0

这个奇怪的版本号的出现一部分也是因为想解决依赖冲突。该jar包自带的pom文件<description>中有相关说明：

An empty artifact that Guava depends on to signal that it is providing ListenableFuture -- but is also available in a second "version" that contains com.google.common.util.concurrent.ListenableFuture class, without any other Guava classes. The idea is:

- If users want only ListenableFuture, they depend on listenablefuture-1.0.

- If users want all of Guava, they depend on guava, which, as of Guava 27.0, depends on listenablefuture-9999.0-empty-to-avoid-conflict-with-guava. 

The 9999.0-... version number is enough for some build systems (notably, Gradle) to select that empty artifact over the "real" listenablefuture-1.0 -- avoiding a
conflict with the copy of ListenableFuture in guava itself. If users are using an older version of Guava or a build system other than Gradle, they may see class conflicts. If so, they can solve them by manually excluding the listenablefuture artifact or manually forcing their build systems to use 9999.0-....

虽然guava中也有ListenableFuture的实现，但是如果用户仅想用listenableFuture的话，可以仅依赖于版本号正常的 listenablefuture-1.0而无需使用任何其他guava相关依赖。

guava其优势在于整洁：把所有东西都放在了同一个依赖jar中，不会有乱七八糟的子jar造成复杂的依赖关系；但其问题也因此而生：该jar包太过庞大，可能会因为一个小功能点而引入一大堆不需要的鸡肋代码。

另一个问题在于，Google很多底层代码是共用的，例如Android和guava，com.google.common.util.concurrent.internal.InternalFutures路径一模一样，因此会报错路径冲突而无法编译通过。于是他们想出来这么一招：把listenableFuture独立出来，然后在两个地方分别引用，这样就可以让gradle, maven等工具通过依赖管理自动解决该问题，而且能单独仅使用listenableFuture而不引入guava那一大堆。