Java模块（JPMS/Jigsaw）能否解决依赖Shading应对的版本冲突问题？

问题背景 #

Java项目中常用Shading处理依赖的核心场景如下：

• 库Foo依赖Bar 1.0，且无法升级至Bar 2.0
• 项目Qux同时依赖Foo和Bar 2.0
• 不做Shading时，Bar的两个版本会在类路径上冲突，因此Foo通常会将Bar 1.0做Shading处理，避免影响下游使用不同Bar版本的项目

核心结论 #

JPMS（Java平台模块系统，即Jigsaw）在满足特定条件的前提下，可以无需Shading解决这类依赖版本冲突，但并非所有场景都适用。

JPMS的解决逻辑 #

1. 模块级隔离
   JPMS基于模块路径（module path）而非传统类路径（classpath）运行，每个模块拥有独立的类空间。如果Bar 1.0和Bar 2.0被定义为不同的JPMS模块（比如模块名分别设为com.example.bar.v1和com.example.bar.v2），那么：

• Foo的module-info.java可明确声明依赖com.example.bar.v1
• Qux的module-info.java可同时声明依赖Foo和com.example.bar.v2
  JPMS会为两个版本的Bar模块维护独立的类加载环境，不会出现类路径冲突。

2. 版本依赖声明
   JPMS允许在module-info.java中指定依赖的版本范围，配合支持模块解析的构建工具（如Maven、Gradle），能准确引入所需版本的模块，避免版本覆盖问题。

限制条件 #

JPMS的解决方案并非万能，存在以下前提：

• 所有组件必须完全适配JPMS：Foo、Bar 1.0、Bar 2.0、Qux都必须包含合法的module-info.java，且不同版本的Bar不能使用相同的模块名——如果两个版本的Bar模块名一致，JPMS依然无法区分，冲突会依然存在。
• 避免跨模块类实例传递：如果Foo需要将Bar 1.0的类实例传递给Qux，而Qux期望的是Bar 2.0的实例，会直接引发ClassCastException。这种场景下Shading依然是更稳妥的方案，因为Shading会重命名Bar的包名，从根本上避免类的混淆。

总结 #

当所有涉及的组件严格遵循JPMS规范，且不同版本的依赖使用不同模块名时，JPMS可以替代Shading解决版本冲突；但如果模块名重复或存在跨版本类实例传递的需求，Shading仍然是必要的处理方式。

内容的提问来源于stack exchange，提问作者clay