全球网站访问量排名,网页数据可视化设计案例,网站开发项目 工作分解图,路由器电脑可以做网站主机如何解决版本不兼容Jar包冲突问题
引言 “老婆”和“妈妈”同时掉进水里#xff0c;先救谁#xff1f; 常言道#xff1a;编码五分钟#xff0c;解冲突两小时。作为Java开发来说#xff0c;第一眼见到ClassNotFoundException、 NoSuchMethodException这些异常来说…如何解决版本不兼容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高版本的代码拷出来直接放到我们的工程中去但是这样做会带来几个问题 1Guava作为一个功能丰富的基础库某一部分的代码往往与其他很多代码都存在依赖关系这会造成牵一发而动全身工作量会比预想的要大很多 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 version1.0 encodingUTF-8?project xmlnshttp://maven.apache.org/POM/4.0.0 xmlns:xsihttp://www.w3.org/2001/XMLSchema-instancexsi:schemaLocationhttp://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsdmodelVersion4.0.0/modelVersiongroupIdcom.shaded.example/groupIdartifactIdguava-wrapper/artifactIdversion${guava.wrapper.version}/versionnameguava-wrapper/nameurlhttps://example.com/guava-wrapper/urlpropertiesproject.build.sourceEncodingUTF-8/project.build.sourceEncoding!- 版本与 guava 版本基本保持一致 -guava.wrapper.version27.1-jre/guava.wrapper.versionmaven.compiler.source1.8/maven.compiler.sourcemaven.compiler.target1.8/maven.compiler.target/propertiesdependenciesdependencygroupIdcom.google.guava/groupIdartifactIdguava/artifactIdversion27.1-jre/version/dependency /dependenciesbuildpluginsplugingroupIdorg.apache.maven.plugins/groupIdartifactIdmaven-compiler-plugin/artifactIdversion3.3/versionconfigurationsource${maven.compiler.source}/sourcetarget${maven.compiler.target}/target/configuration/pluginplugingroupIdorg.apache.maven.plugins/groupIdartifactIdmaven-jar-plugin/artifactIdversion2.3.2/versionexecutionsexecutioniddefault-jar/idgoalsgoaljar/goal/goalsphasepackage/phase/execution/executions/pluginplugingroupIdorg.apache.maven.plugins/groupIdartifactIdmaven-source-plugin/artifactIdversion2.4/versionexecutionsexecutioniddefault-sources/idgoalsgoaljar-no-fork/goal/goals/execution/executions/pluginplugingroupIdorg.apache.maven.plugins/groupIdartifactIdmaven-shade-plugin/artifactIdversion2.4.1/versionconfigurationcreateDependencyReducedPomfalse/createDependencyReducedPom/configurationexecutionsexecutionphasepackage/phasegoalsgoalshade/goal/goalsconfiguration!-- 重命名规则配置 --relocationsrelocation!-- 源包路径 --patterncom.google.guava/pattern!-- 目标包路径 --shadedPatterncom.google.guava.wrapper/shadedPattern/relocationrelocationpatterncom.google.common/patternshadedPatterncom.google.common.wrapper/shadedPattern/relocationrelocationpatterncom.google.thirdparty/patternshadedPatterncom.google.wrapper.thirdparty/shadedPattern/relocation/relocationstransformerstransformerimplementationorg.apache.maven.plugins.shade.resource.ManifestResourceTransformer//transformers/configuration/execution/executions/plugin/plugins/builddistributionManagement!- Maven仓库配置略 -/distributionManagement
/project项目引入这个新打包的guava-wrapper后import选择从这个包导入我们需要的相关类即可。如下 dependencygroupIdcom.vivo.internet/groupIdartifactIdguava-wrapper/artifactIdversion27.1-jre/version
/dependency结语
为了在同一个项目中使用多个版本不兼容的Jar包我们首先想到手动自行维护代码但是工作量和维护成本很高接着我们想到通过类加载器隔离开源方案SOFAArk但是需要将相关依赖都打包成Ark Plugin解决方案无疑有点过重了最后通过maven-shade-plugin插件重命名并打包优雅地解决了项目中不兼容多个版本Jar包的冲突问题。从问题出来我们一步一步探寻问题的解决方案最终的maven-shade-plugin插件方案虽然看似与手动自行维护代码本质一致看似回到了原点但其实最终的方案优雅性远比最开始高得多正如人生的道路那样螺旋式上升曲线式前进。如果遇到类似需要支持版本不兼容Jar包共存的场景可以考虑使用maven-shade-plugin插件这种方法比较轻量级可用于项目中存在个别不兼容Jar包冲突的场景简单有效成本也很低。但是如果Jar包冲突现象比较普遍已成为明显或者普遍的痛点还是建议考虑文中提到的类似Pandora、SOFAArk等类加载器隔离的方案。
