解决版本不兼容Jar包冲突问题

 更新时间:2023年10月03日 10:53:33   作者:IT枫斗者  
在和三方对接的过程中,我们可能会不断引入一些三方jar包,但这个时候就有可能出现一个项目需要依赖两个版本不同且功能不兼容的jar包,本文主要介绍了解决版本不兼容Jar包冲突问题,感兴趣的可以了解一下

引言

“老婆”和“妈妈”同时掉进水里,先救谁?

常言道:编码五分钟,解冲突两小时。作为Java开发来说,第一眼见到ClassNotFoundException、

NoSuchMethodException这些异常来说,第一反应就是排包。经过一通常规和非常规操作以后,往往会找到同一个Jar包引入了多个不同的版本,这时候一般排除掉低版本、保留高版本就可以了,这是因为一般Jar包都是向下兼容的。但是,如果出现版本不兼容的情况的时候,就会陷入“老婆和妈同时掉进水里,先救谁”的两难境地,如果恰恰这种不兼容发生在中间件依赖和业务自身依赖之间,那就更难了。 如下图所示,Project表示我们的项目,Dependency A表示我们的业务依赖,Dependency B表示中间件依赖,如果业务依赖和中间件依赖都依赖同一个Jar包C,但是版本却不一样,分别为0.1版本和0.2版本,而且最不巧的是这两个版本还存在冲突,有些老的功能只在0.1低版本中存在,有些新功能只在0.2高版本中存在,真是“老婆和妈同时掉进水里,先救谁都不行”。

俗话说:没有遇到过Jar包冲突的开发,一定是个假Java开发;没有解决过Jar包冲突的开发,不是一个合格的Java开发。在最近的项目里,我们需要使用Guava的高版本Jar包,但是发现中间件依赖的是低版本且与高版本不兼容的Jar包,面对这种两难,我们肯定是“老婆”和“妈妈”都要救,于是我们开始寻求解决方案。

不兼容依赖冲突解决方案

“老婆”和“妈妈”都要救,怎么救?

首先,我们想到的是,能不能把需要用到的Guava高版本的代码拷出来直接放到我们的工程中去,但是这样做会带来几个问题:

  • 1)Guava作为一个功能丰富的基础库,某一部分的代码往往与其他很多代码都存在依赖关系,这会造成牵一发而动全身,工作量会比预想的要大很多;
  • 2)拷贝出来的代码只能自己手动维护,如果官方修复了问题或者重构了代码或者增加了功能,我们想要升级的话,那么只能重头再来一遍。于是,我们只能另外想其他的方案,这个只能作为最后的兜底方案。

然后,我们在想,一个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的配置如下:

<?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等类加载器隔离的方案。

到此这篇关于解决版本不兼容Jar包冲突问题的文章就介绍到这了,更多相关版本不兼容Jar包冲突内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家!

相关文章

  • MySQL text类型对应mybatis jdbcType类型方式

    MySQL text类型对应mybatis jdbcType类型方式

    这篇文章主要介绍了MySQL text类型对应mybatis jdbcType类型方式,具有很好的参考价值,希望对大家有所帮助,如有错误或未考虑完全的地方,望不吝赐教
    2024-07-07
  • 解决idea删除模块后重新创建显示该模块已经被注册的问题

    解决idea删除模块后重新创建显示该模块已经被注册的问题

    这篇文章主要介绍了解决idea删除模块后重新创建显示该模块已经被注册的问题,具有很好的参考价值,希望对大家有所帮助。一起跟随小编过来看看吧
    2021-02-02
  • Idea调用WebService的关键步骤和注意事项

    Idea调用WebService的关键步骤和注意事项

    这篇文章主要介绍了如何在Idea中调用WebService,包括理解WebService的基本概念、获取WSDL文件、阅读和理解WSDL文件、选择对接测试工具或方式、发送请求和接收响应、处理响应结果以及错误处理,需要的朋友可以参考下
    2025-01-01
  • 详解JAVA 强引用

    详解JAVA 强引用

    这篇文章主要介绍了JAVA 强引用的相关资料,帮助大家更好的理解和学习,感兴趣的朋友可以了解下
    2020-08-08
  • Java爬取豆瓣电影数据的方法详解

    Java爬取豆瓣电影数据的方法详解

    这篇文章主要介绍了Java爬取豆瓣电影数据的方法,结合实例形式详细分析了Java爬取豆瓣电影数据相关原理、操作步骤、实现技巧与注意事项,需要的朋友可以参考下
    2020-04-04
  • 基于Springboot的高校社团管理系统的设计与实现

    基于Springboot的高校社团管理系统的设计与实现

    本文将基于Springboot+Mybatis开发实现一个高校社团管理系统,系统包含三个角色:管理员、团长、会员。文中采用的技术有Springboot、Mybatis、Jquery、AjAX、JSP等,感兴趣的可以了解一下
    2022-07-07
  • JavaWeb学习笔记分享(必看篇)

    JavaWeb学习笔记分享(必看篇)

    下面小编就为大家带来一篇JavaWeb学习笔记分享(必看篇)。小编觉得挺不错的,现在就分享给大家,也给大家做个参考。一起跟随小编过来看看吧
    2016-06-06
  • java的正则表达式你知道多少

    java的正则表达式你知道多少

    这篇文章主要为大家详细介绍了java的正则表达式,使用表格进行介绍,文中示例代码介绍的非常详细,具有一定的参考价值,感兴趣的小伙伴们可以参考一下,希望能够给你带来帮助
    2022-02-02
  • spring源码学习之bean的初始化以及循环引用

    spring源码学习之bean的初始化以及循环引用

    这篇文章主要给大家介绍了关于spring源码学习之bean的初始化以及循环引用的相关资料,文中通过示例代码介绍的非常详细,对大家的学习或者工作具有一定的参考学习价值,需要的朋友们下面随着小编来一起学习学习吧
    2020-10-10
  • Spring注解@Value在controller无法获取到值的解决

    Spring注解@Value在controller无法获取到值的解决

    这篇文章主要介绍了Spring注解@Value在controller无法获取到值的解决,具有很好的参考价值,希望对大家有所帮助。如有错误或未考虑完全的地方,望不吝赐教
    2021-11-11

最新评论