一、引言
“老婆”和“妈妈”同时掉进水里，先救谁？
常言道：编码五分钟，解抵触两小时。作为Java开发来说，第一眼见到ClassNotFoundException、NoSuchMethodException这些异样来说，第一反馈就是排包。通过一通惯例和非常规操作当前，往往会找到同一个Jar包引入了多个不同的版本，这时候个别排除掉低版本、保留高版本就能够了，这是因为个别Jar包都是向下兼容的。然而，如果呈现版本不兼容的状况的时候，就会陷入“老婆和妈同时掉进水里，先救谁”的两难地步，如果恰好这种不兼容产生在中间件依赖和业务本身依赖之间，那就更难了。
如下图所示，Project示意咱们的我的项目，Dependency A示意咱们的业务依赖，Dependency B示意中间件依赖，如果业务依赖和中间件依赖都依赖同一个Jar包C，然而版本却不一样，别离为0.1版本和0.2版本，而且最不巧的是这两个版本还存在抵触，有些老的性能只在0.1低版本中存在，有些新性能只在0.2高版本中存在，真是“老婆和妈同时掉进水里，先救谁都不行”。
（图片摘自：SOFAArk官网）
俗话说：没有遇到过Jar包抵触的开发，肯定是个假Java开发；没有解决过Jar包抵触的开发，不是一个合格的Java开发。在最近的我的项目里，咱们须要应用Guava的高版本Jar包，然而发现中间件依赖的是低版本且与高版本不兼容的Jar包，面对这种两难，咱们必定是“老婆”和“妈妈”都要救，于是咱们开始寻求解决方案。
二、不兼容依赖抵触解决方案
“老婆”和“妈妈”都要救，怎么救？
首先，咱们想到的是，能不能把须要用到的Guava高版本的代码拷进去间接放到咱们的工程中去，然而这样做会带来几个问题：
- Guava作为一个功能丰富的根底库，某一部分的代码往往与其余很多代码都存在依赖关系，这会造成牵一发而动全身，工作量会比料想的要大很多；
- 拷贝进去的代码只能本人手动保护，如果官网修复了问题或者重构了代码或者减少了性能，咱们想要降级的话，那么只能重头再来一遍。于是，咱们只能另外想其余的计划，这个只能作为最初的兜底计划。
而后，咱们在想，一个Java类被加载到JVM虚拟机里区别于另一个Class，其一是它们俩全门路不一样，是驴唇不对马嘴的两个不同的类，但却是被不同的类加载器加载的，在JVM虚拟机里它们依然被认为是两个不同的Class。所以，咱们就在想从类加载器上来寻求解决方案。在阿里巴巴外部，有一个Pandora的组件，正如其名就像一个魔盒，它会把中间件的依赖都装到Pandora里（外部叫做Sar包），这样的话，就能防止在中间件和业务代码间接呈现“老婆和妈同时掉进水里，先救谁”的两难地步。
同样，在相似的场景比方利用合并部署也能施展威力。然而Pandora只在阿里外部应用并未开源。在蚂蚁金服，也有一个这样的组件，并且开源了，叫做SOFAArk（官网网址，感兴趣的能够去官网理解SOFAArk的原理和应用），咱们感觉曾经找到了那个Mr.Right，于是咱们开始钻研SOFAArk如何应用。和Pandora一样，SOFAArk也是通过应用不同的 ClassLoader 加载不同版本的三方依赖，进而隔离类，彻底解决包抵触的问题，这就要求咱们须要将相干的依赖打包成Ark Plugin（参见SOFAArk官网文档）。
对于公司来说，这样的计划收益是比拟大的，打包成Ark Plugin后整个公司都可能共享，业务方都能受害，然而对于咱们一个我的项目来说，采纳这样的计划无疑过重了。于是，咱们与中间件同学分割，询问是否有打算引入相似的隔离组件解决中间件和业务代码之间的依赖抵触问题，失去的回答是公司目前包抵触并不是一个强烈的痛点，临时没有打算引入。于是，咱们只能暂且搁置SOFAArk，持续寻找新的解决方案。
接着，咱们在想既然Pandora/SOFAArk采纳类加载隔离了同一门路的类，那么如果咱们把抵触的两个版本库的groupId变得不一样，那么即便同名的类全门路也是不一样的，这样在JVM外面必然是不同的Class。如果把Pandora/SOFAArk的隔离形式称之为逻辑隔离的话，这种就相当于物理隔离了。要实现这一点，借助IDE的重构性能或者全局替换的性能就能比拟容易的实现这一点。
正在咱们筹备撸起袖子入手干的时候，咱们不禁在想，这样的痛点应该早就有人遇到，尤其像Guava、Commons这类的根底类库，抵触在劫难逃，前人应该曾经找到了优雅的挠痒姿态。于是，咱们就去搜寻相干的文章，果不其然，maven-shade-plugin正是那优雅的挠痒姿态，这个Maven插件的原理正是将类的包门路进行从新映射，达到隔离不兼容Jar包的目标。
三、maven-shade-plugin解决依赖抵触
最初如何来配置和应用maven-shade-plugin将Guava映射成咱们本人定制的Jar包，实现与中间件Guava的隔离。整个的过程还是比拟清晰明了的，次要是创立一个Maven工程，引入依赖，配置咱们要公布的仓库地址，引入编译打包插件和maven-shade-plugin插件，配置映射规定（标签之间局部），而后编译打包公布到Maven仓库。pom.xml的配置如下：
<code class="java"><?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>com.shaded.example</groupId>
<artifactId>guava-wrapper</artifactId>
<version>${guava.wrapper.version}</version>
<name>guava-wrapper</name>
<url>https://example.com/guava-wrapper</url>
<properties>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
<!- 版本与 guava 版本根本保持一致 ->
<guava.wrapper.version>27.1-jre</guava.wrapper.version>
<maven.compiler.source>1.8</maven.compiler.source>
<maven.compiler.target>1.8</maven.compiler.target>
</properties>
<dependencies>
<dependency>
<groupId>com.google.guava</groupId>
<artifactId>guava</artifactId>
<version>27.1-jre</version>
</dependency>
</dependencies>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.3</version>
<configuration>
<source>${maven.compiler.source}</source>
<target>${maven.compiler.target}</target>
</configuration>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<version>2.3.2</version>
<executions>
<execution>
<id>default-jar</id>
<goals>
<goal>jar</goal>
</goals>
<phase>package</phase>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-source-plugin</artifactId>
<version>2.4</version>
<executions>
<execution>
<id>default-sources</id>
<goals>
<goal>jar-no-fork</goal>
</goals>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-shade-plugin</artifactId>
<version>2.4.1</version>
<configuration>
<createDependencyReducedPom>false</createDependencyReducedPom>
</configuration>
<executions>
<execution>
<phase>package</phase>
<goals>
<goal>shade</goal>
</goals>
<configuration>
<!-- 重命名规定配置 -->
<relocations>
<relocation>
<!-- 源包门路 -->
<pattern>com.google.guava</pattern>
<!-- 指标包门路 -->
<shadedPattern>com.google.guava.wrapper</shadedPattern>
</relocation>
<relocation>
<pattern>com.google.common</pattern>
<shadedPattern>com.google.common.wrapper</shadedPattern>
</relocation>
<relocation>
<pattern>com.google.thirdparty</pattern>
<shadedPattern>com.google.wrapper.thirdparty</shadedPattern>
</relocation>
</relocations>
<transformers>
<transformer
implementation="org.apache.maven.plugins.shade.resource.ManifestResourceTransformer"/>
</transformers>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
<distributionManagement>
<!- Maven仓库配置，略 ->
</distributionManagement>
</project>
我的项目引入这个新打包的guava-wrapper后，import抉择从这个包导入咱们须要的相干类即可。如下：
<dependency> <groupId>com.vivo.internet</groupId> <artifactId>guava-wrapper</artifactId> <version>27.1-jre</version> </dependency>
四、结语
为了在同一个我的项目中应用多个版本不兼容的Jar包，咱们首先想到手动自行保护代码，然而工作量和保护老本很高，接着咱们想到通过类加载器隔离（开源计划SOFAArk），然而须要将相干依赖都打包成Ark Plugin，解决方案无疑有点过重了，最初通过maven-shade-plugin插件重命名并打包，优雅地解决了我的项目中不兼容多个版本Jar包的抵触问题。从问题进去，咱们一步一步探寻问题的解决方案，最终的maven-shade-plugin插件计划尽管看似与手动自行保护代码实质统一，看似回到了原点，但其实最终的计划优雅性远比最开始高得多，正如人生的路线那样，螺旋式回升，曲线式后退。
如果遇到相似须要反对版本不兼容Jar包共存的场景，能够思考应用maven-shade-plugin插件，这种办法比拟轻量级，可用于我的项目中存在个别不兼容Jar包抵触的场景，简略无效，老本也很低。然而，如果Jar包抵触景象比拟广泛，已成为显著或者广泛的痛点，还是倡议思考文中提到的相似Pandora、SOFAArk等类加载器隔离的计划。
作者：vivo互联网服务器团队-Zhang Wei
转载请注明原文链接：关于java:版本不兼容Jar包冲突该如何是好
