【IT168 资讯】Mark Reinhold前些天公布了Java模块化的第一份公开草案。正如Mark在有关这个问题的博客里说的，这次关于Java模块化的讨论和先前的JSR294迭代有所不同，这次讨论不是Sun/Oracle关起门来进行的，而是引入了参与OpenJDK的其他成员，比如IBM，还有Java SE和Java EE社区的其他成员。

　　由于这只是一份草案，有些问题仍然需要商讨，但它已经对什么是Java模块化进行了统一的定义。有IBM的参与，这份草案比以往更加关注与OSGi之间的互操作性。

　　有个比较有意思的需求是，即便ServiceLoader和ResourceBundle在Java模块化里的表现并不尽如人意，但模块化还是想基于这两部分内容构建，以便那些想用标准模式的开发人员不用关注细节就可以利用模块化。目前，ServiceLoader在处理多个类加载器的时候还有问题。

　　让JVM模块化的主要目的之一是对JVM库进行分割，JVM库这些年已经增长到了几十兆。(不处理模块化概念的Scala也已经有十兆了)。不过JVM库里所有的类都在同一个类加载器里;而OSGi是每个Bundle有一个类加载器，这就不能进行直接的映射。(OSGi有片段的概念，片段能把自己写到父类加载器里去)。文档里有一部分需求定义到，要支持有单独类加载器的模块系统和提供多个类加载器方法的模块系统。

　　文档里有些描述还比较模糊。比如说，要求版本完全有序，但似乎还没有像Semantic Versioning这样一致的版本化方法。此外，文档要求严格定义元数据(版本号是其中一部分)，而版本的概念还有待商榷。

　　另一个悬而未决的问题是，模块信息是否应该像编译好的Java代码或可声明的外部库那样使用。OSGi利用已有的MANIFEST.MF文件处理编码依赖，先前的Jigsaw实现则编译一个Java类文件，允许通过库进行内省。这对Java变种有一个不利影响，就是Mirah或JRuby等非Java语言使用模块系统会更加困难。

　　这个需求貌似还有较大争议。虽然JRuby的领导者Charles Nutter说他还没来得及阅读完整的规范，但他在Reinhold的博客里评论说。

　　Jigsaw模块化系统要求有一个可能包含注解的.class文件，因此也没必要限制参与语言：

• 　　发布前要先编译成JVM字节码。
• 　　支持全部的Java语言结构，比如源码级的注解。

　　换句话说，JRuby、JavaScript(Rhino)、各个版本的Smalltalk、Python(Rhino)及其它几种语言会立即被排除在外了。

　　提案还谈到了通用打包系统(比如rpm和easy_install)，借助这类系统可以把Java运行时传递给其他系统和已在网络上发布的工件。和模块化相比，对这部分的论述要稍微深入一点儿。

　　这份提案虽然尚未完成、还有待解决的问题，但已经收到了一些积极的反馈：

　　文档里还有很多很多好的需求，这些需求要是都能以开放和兼容的方式实现，Java一定会从中获益。

　　另一个好处是，一旦模块化成为Java SE 8的一部分，向OSGi转会比现在容易得多。现在要想把已有系统往OSGi上迁移，最大的障碍往往是系统的模块化，因为系统最初就不是以模块的方式构建的。这不是OSGi本身的问题，而是模块化概念的问题。你要是有非模块化的代码，就很难对它们进行模块化。在Java SE 8里，这个问题会在开发周期的更早期出现，这有助于开发人员从一开始就用模块的方式去设计系统。如果基本的JVM模块系统不能满足你的需求，你可以把已有的Java SE 8模块转到OSGi上，这些模块还会按原来的样子运行，所以迁移变得轻而易举。然后你就可以利用OSGi的优势对模块进行增强了(见下文)。

　　Java的模块化可能会使OSGi-lite模式成为现实，会鼓励Java库的开发人员使用模块元数据对他们的运行时进行注解，而这些元数据都能被OSGi运行时使用。在任何情况下，就算有一些已知的分歧，只要用一种兼容而合理的方式前进，对所有Java(和基于Java)的开发人员就都有好处。

　　你怎么看提出的这些模块化需求呢？