Nicolai Parlog是一位热情的软件工程师，数字版权与开源软件的狂热拥护者；他对AssertJ、ControlsFX、FindBugs及Property Alliance等项目都做出过重要的贡献。近日，Parlog就Jigsaw项目撰写了一篇文章，谈到了Jigsaw项目的一些不足以及改进之处。Jigsaw项目有着雄心勃勃的宏伟目标，其目标之一就是彻底摆脱极易出错且问题多多的类路径机制中的JAR地狱问题。不过，虽然该项目的其他目标会在不久的将来得以实现，但解决JAR地狱问题这一目标似乎并不是那么容易的。
为了更好地理解我们接下来要讨论的内容，首先来看一下JAR地狱问题，接下来介绍Jigsaw项目将会解决问题的哪些方面，以及为什么说Jigsaw所尝试解决的问题并不会对整个问题域产生本质的影响。最后，我们来看一下官方对于这个话题的立场，并给出如何防止出现模块地狱的提案。
JAR地狱问题
JAR地狱存在着如下循环问题：
表述不清以及传递性依赖
遮蔽
版本冲突
复杂的类加载
根据构建工具与组件系统（JDK开发者称之为容器）为我们所带来的诸多功能与特性，我们可以认为表述不清以及传递性依赖问题已经在很大程度上得到了解决，遮蔽问题至少得到了缓解，而复杂的类加载也不再是老生常谈的问题了。这样，版本冲突就成为JAR地狱中最为严重的一个问题了，它影响到了很多很多项目每天的更新决策。
Jigsaw将会带来哪些改变？
我之前曾就Jigsaw项目会为Java 9带来哪些新特性专门写过文章进行过介绍，不过这里将从不同的视角进行阐述。首先，它会受到当前的早期访问构建版的影响；其次，我们这里只从与JAR/模块地狱相关的角度进行介绍。
Jigsaw为Java带来的核心概念就是模块化。简而言之，模块就像JAR一样，同时带有一些附加信息与特性。这些信息包含了模块的名字以及模块所依赖的其他模块的名字。
依赖
当编译器与JVM在处理模块时，他们会解析这些信息。在编译或启动时，他们会通过模块路径传递性解析所有依赖。总体来说，这类似于类路径扫描，不过现在寻找的是整个模块而非单个类，对于JVM来说，这是在启动期而非运行期进行的。如果在模块路径上无法找到所有依赖，那么解析模块的传递性依赖就会失败。这显然可以解决表述不清，以及无休止的传递性依赖的问题。我认为这是个很棒的做法，Java语言现在正式知道关于依赖的信息了，所有工具（编译器与JVM等）都能理解这一点并正常使用！不过，我认为这并不会对开发者每天的工作产生多少积极的影响，因为现在很多既有的基础设施都已经解决这个问题了，比如说构建工具等。
遮蔽
Jigsaw消除了遮蔽的问题。模块系统可以确保每个依赖都会被另一个模块所实现，每个模块都会读取至多一个模块，定义了同名包的模块之间并不会相互干扰。更准确地说，模块系统在遇到模糊不清的情况时就会终止并报错，比如说两个模块将相同的包导出到相同模块中。
版本冲突
我们认为第三方库的版本冲突是JAR地狱最为难以解决的问题。最直接的解决方案就是一个模块系统能够加载同一个模块的不同版本。这需要确保这些版本之间不存在互相交互的情况。问题在于：在单个配置中，没必要支持一个模块的多个版本。实际上，当前的构建既不会创建，也无法理解模块版本信息。曾有人使用了一些变通办法。最丑陋，同时也是最可行的办法就是重命名出现冲突的构件，这样他们就不再是相同模块的两个不同版本了，而是两个完全不同的模块。不过，这种做法最后证明也是行不通的。显然，确保“定义了同名包的模块之间不会相互干扰”是在两个模块导出相同包时拒绝任何启动配置来实现的。即便没有模块读取他们亦如此！
复杂的类加载
模块与类加载器之间如何交互以及如何改变类加载的复杂性是个很棘手的问题。实际上，模块系统对模块与类加载器之间的关系并没有做多少限制。类加载器可以从一个模块或是多个模块来加载类型，只要模块之间不存在相互干扰的情况，并且每个模块中的类型只由一个加载器加载即可。因此，类加载器与模块之间是一对多的关系。
模块地狱？
既然依赖与遮蔽问题已经得到了解决，并且类加载问题也得到了改进，那我为何还要讨论模块地狱呢？就是因为版本冲突么？没错！如果Jigsaw想要解决JAR地狱问题，它就需要特别注意版本冲突问题。否则，很多项目并不会出现什么起色。他们依然要面对版本冲突问题，并且会陷入到自定义类加载器的梦魇中。
提案