用于小型应用程序/库的JPMS /项目拼图的优点
我了解大型应用程序的Java平台模块系统（JPMS）的优点，但是有什么理由将小型库或应用程序整合到一个（单个）模块中？如果是这样，Modular Jar Files是实现这一目标的最佳方法，还是普通方法是首选？未来，模块化v类路径程序会有性能影响吗？用于小型应用程序/库的JPMS /项目拼图的优点
如果是这样，是模块化的Jar文件实现该目标的最佳手段，或者是正常的做法首选？
我不知道你，你通过“正常途径”的意思 -是“正常途径”创建模块系统将自动生成一个模块文物。
[我有什么理由将一个小型库或应用程序放入（单个）模块中？
是的，有几个：
开发者创建一个模块化的应用程序，或利用reliable configuration，他们如果所有的依赖是目前只能推出自己的应用程序中的模块化磁带库的好处 - 这是一个好处没有关于应用程序/库的大小。
作为一个库设计师，你可以隐藏内部。虽然strong encapsulation仅在将模块化JAR放置到模块路径中时才有效，但模块描述符仍然会将您的意图记录在代码中，并允许您更改地更改代码。应用程序开发人员也会受益，因为他们不会再意外地依赖于不受支持的实现细节。
即使在小型应用程序和库中，服务也可能用于分离功能的不同方面，并使代码更易于扩展。
通过
jlink，运行图像中只能包含“真实”模块（与自动模块相对）。不提供模块化的JAR会让您的用户遇到这种可能性。
还要注意，你永远不知道哪个小应用程序或库可能变成更大的东西。 :)
展望未来，模块化v类路径程序会有性能影响吗？
在构建模块图和验证模块花费的时间，该模块系统应具有改进的类加载策略弥补：它记录了每个包的模块将其导出和负载类型从包直接从该模块而不必扫描整个课程路径。无论如何，我不认为这应该是一个决定性因素。
发现这个链接信息
http://www.javaworld.com/article/2878952/java-platform/modularity-in-java-9.html
是不是JAR文件模块化就够了吗？
JAR文件和它们在其中运行的部署环境极大地提高了 对许多旧版部署约定的改进。 但JAR文件除了隐藏在.jar清单中的很少使用的 版本号之外，没有固有的唯一性。 JAR文件和 可选清单在Java运行时环境中不被用作 内的模块化惯例。因此， 文件中的类的包名称以及它们对类路径的参与是JAR结构的唯一部分，它为运行时环境提供了模块化特性。
简而言之，JAR是模块化的一个很好的尝试，但它们不会满足真正模块化环境的所有要求。 Spring和OSGi等框架和平台使用模式，并增强了JAR规范，为构建功能强大的模块化系统的环境提供了 。然而，随着时间的推移，这些工具甚至会屈服于JAR规范JAR地狱的一个非常不幸的副作用！
的Classpath/JAR地狱
当Java运行时环境允许任意复杂的JAR 装载机制，开发人员知道他们在类路径地狱或JAR 地狱。许多配置可能导致这种情况。
首先，考虑Java应用程序开发人员 提供应用程序的更新版本并将其打包到 中的一个与旧版本名称完全相同的JAR文件的情况。 Java运行时环境不提供确认 正确JAR文件的验证工具。运行时环境将简单地从JAR文件中加载类 ，该文件首先找到或满足许多 类路径规则之一。这最多会导致意想不到的行为。
JAR地狱的另一个实例出现在两个或多个应用程序或进程依赖于不同版本的第三方库的地方。使用 标准类加载设施，只有一个版本的第三方库会在运行时可用，导致至少在一个应用程序或进程中出现错误。
一个全功能和高效的Java模块系统应该有助于将代码分离成不同的，易于理解的和松散的 耦合模块。应明确指定相关性，并严格执行 。设施应该是可用的，允许升级模块 而不会对其他模块产生负面影响。运行时环境的模块化应该支持特定于特定域或垂直市场的配置，从而减少启动时间和环境的系统占用空间。
为Java
模块化解决方案，除了到目前为止提到的模块化功能，最近的努力 补充一些。以下功能旨在优化 性能，使延伸的运行环境：
分段的源代码： 源代码分离成不同的，高速缓存段，每个段的 包含特定类型的编译代码。其目标包括在垃圾扫描期间跳过非方法代码的 ，增量构建， 和更好的内存管理。
构建时执行：强制执行命名空间的语言构造， 版本控制，依赖性和其他。
部署设施：支持 为根据具体需要部署缩放的运行时环境， 如那些移动设备的环境的