JDK 9：模块系统状态的重点

马克·雷因霍尔德（ Mark Reinhold ）的“模块系统状态（SOMS）”已于本月初发布，它提供了信息丰富的可读性“对项目Jigsaw中原型的Java SE平台进行了增强的非正式概述，并被提议作为JSR 376的起点。” 在这篇文章中，我总结并突出了一些我在阅读文档时发现有趣的概念和术语。

模块系统状态指出Java开发人员将定期使用文档中讨论的部分功能。这些功能和概念是“模块声明，模块化JAR文件，模块图，模块路径和未命名模块”。
模块是“一种基本的新型Java程序组件”，是“一个自命名的，自定义的代码和数据集合”。
“一个模块声明需要其他哪些模块才能进行编译和运行。”
- requires关键字似乎类似于OSGI的要求，捆绑或进口包装
“一个模块声明了......其打包出口 ”到其他模块。
- exports关键字似乎类似于OSGI的Export-Package 。
模块声明是“ Java编程语言的新构造”，提供了“模块的自我描述”。
- 惯例是将“模块声明的源代码”放在“模块源文件层次结构根目录中名为module-info.java的文件中”。
“模块名称，如程序包名称，不得冲突。”
“模块的声明不包括版本字符串，也不包含对其依赖的模块的版本字符串的约束。”
“ 模块化的JAR文件在所有可能的方式上都与普通的JAR文件类似，除了它的根目录中还包含module-info.class文件。”
“模块化的JAR文件允许库的维护者发布单个工件，该工件既可以在Java 9及更高版本上作为模块使用，又可以在所有版本中作为类路径上的常规JAR文件使用。”
“ 基本模块定义并导出了平台的所有核心软件包”，“被命名为java.base ”，是“模块系统唯一已知的唯一模块”，“始终存在”，并由所有其他模块所依赖，并且不依赖其他模块。
所有“平台模块”均以“ java. ”开头java. 前缀和“可能包括“用于数据库连接的 java.sql ，用于XML处理的 java.xml和用于日志记录的 java.logging 。”
前缀“ jdk. ”应用于“ Java SE 9平台规范中未定义的模块”，但“特定于JDK”的名称。
隐含可读性 ：关键字public可以在之后添加requires关键字状态给定的模块的模块读取可以通过读取它依赖模块读取。换句话说，如果模块B根据requires public引用了模块C提供的包，则该包可由可以读取模块B的模块A读取。
通过使用关键字的在Java模块系统便于“经由服务接口和服务提供商的程序组件的松耦合” provides ... with ...以指示何时一个模块提供的服务的实现，并通过使用关键字uses指示模块何时使用提供的服务。
因为给定的类与单个模块关联，所以Class::getModule()将允许访问类的关联模块。
“每个类加载器都有一个唯一的未命名模块 ”，从中加载与模块公开的包无关的类型。可以使用新方法ClassLoader::getUnnamedModule检索给定的类加载器的未命名模块。
- 未命名的模块可以读取所有其他模块，并且可以被所有其他模块读取。
“ JMOD”是“新工件格式”的“临时”名称，“新工件格式”“超出JAR文件”，用于保存“本机代码，配置文件和其他自然不适合…放入JAR文件中的数据”。目前，这是JDK的一部分，有可能在以后的Java SE中进行标准化。

上面概述的项目不包括“模块系统状态”中涵盖的“高级主题”，例如合格的出口，增加的可读性和层次。原始文档也值得一读，因为它具有更深入的说明，简短的代码清单和说明性图形。

拼图项目和OSGi

与OSGi一样，Project Jigsaw旨在在基于Java的应用程序中实现更大的模块化。我期待看到内置的模块化支持是否可以提供与OSGi提供的某些相同的优点，同时消除或减少与OSGi相关的一些缺点。杰西卡·桑恩斯比（Jessica Thornsby）在Mule Drop OSGi For Beo 太复杂的文章中，总结了一些开发人员对OSGi的劣势的看法，这些想法导致Spring和Mule等停止使用OSGi。 Thornsby的文章引用了Dmitry Sklyut ， Kirk Knoerschild和Ian Skerrett的话，他们认为更好的工具，更好的文档（包括社区），在会议上更好的曝光以及通过使用获得更多的熟悉度将有助于OSGi的采用并有助于克服被认为是艰难的学习曲线和复杂性。

我很好奇，如果Java平台内置的模块化功能几乎可以自动带来OSGi倡导者认为可以提高OSGi的采用率的某些功能。我怀疑Project Jigsaw通过内置到平台中会获得更好的工具支持，更好地面向一般Java开发人员，并且会在Java开发人员社区（博客，会议，书籍等）中得到更广泛和广泛的覆盖。凭借这些优势，我还想知道Java 9和Jigsaw是否会导致OSGi的当前用户离开OSGi，或者这些用户是否会找到创造性的方式来将两者一起使用或会做自己能做的事情（例如使用未命名的模块）使用OSGi而不是拼图。由于OSGi可以在Java 9之前的Java版本上运行，而Jigsaw仅在Java 9和更高版本上可以运行，因此在Java 9的采用升温之前，可能不会急于将基于OSGi的应用程序迁移到Jigsaw。 Java 9的模块化：与Project Jigsaw，Penrose和OSGi堆叠在一起，可以对当前和即将到来的Java模块化方法进行有趣的讨论。