Java运⾏期的jar版本冲突控制解决思路
解决思路:
⼀般来说，在⽐较⼤的项⽬⾥，依赖冲突这种事情⼏乎是⽆法避免的。⼀般来说，这种问题的解决⽅法⼤多是下⾯⼏种：
- 对于业务⽅来说，写代码的时候⼩⼼⼀点，遇到不同依赖的时候，有意识的检查⼀下依赖树，尽量使⽤较新的包，并且代码上线之前需要在测试环境充分测试。
- 对于组件开发⽅来说，在写接⼊⽂档的时候要同时指明依赖的包的最低版本号，清楚地告诉接⼊⽅最低的依赖，然后再由接⼊⽅⼿动指定。
- 使⽤Shade技术，对于组件开发⽅来:说，将需要依赖的第三⽅包shade进⾃
⼰的代码，使⽤“⾃⼰包名的前缀+实际包名”来进⾏隔离。
- 采⽤容器技术，⽐如OSGI、Jigsaw、Karaf这些容器，对jar包再进⾏⼀层权限控制。这是⼀种⼗分重量级的⽅法，⼀般项⽬得上了⼀定的规模才会使
⽤。
- 采⽤ClassLoader隔离技术，各个包都使⽤⾃⼰的classLoader，互相不影
响。这种⽅法其实很像是容器技术的阉割版，逻辑上很像容器，对jar包再做⼀层隔离控制。不过这种⽅式⼀般不是很优雅，有点像hack，因此⽬前看起来没什么像样的完整解决⽅案。稍微像样点的⼤概就是阿⾥最近搞的Sofa ark，功能挺强⼤，但是⽤起来也⽐较复杂，对jar包的侵⼊性也很强。
各个⽅法其实都不是很⽅便，那就换⼀个思路，既然避免问题⽐较困难，那就尽量早点暴露问题。编译错误或者启动错误肯定会⽐运⾏时不知道啥时候报错更让⼈放⼼。因此根据 fail fast 原则，我们应当保证在不增加沟通成本的情况下，快速暴露问题。分析
既然很多依赖冲突问题在编译、打包时都不会报错，那就只能尽量在启动时报错了。因此对于⼀个稳定的组件来说，做⼀个运⾏时的启动检查也就有⼀定的合理性了。
为了能在运⾏时进⾏依赖检查，肯定要想办法在运⾏时获得某个包的版本号。那如何在打包时把版本信息写在jar包⾥，然后再读出来呢？这就要从JarFile的加载说起了。