Jigsaw蓄势待发

Java 7有三个主要目标。首先是通过Jigsaw项目模块化Java平台。第二是通过invokeDynamic指令和达芬奇机项目将JVM发展为多语言平台，第三是通过项目Coin来解决Java程序员面对的一些常见生产效率问题。

将Java平台模块化带来了许多好处：通过消除JDK里众多类之间日益增长的相互依赖而改善了性能；由于允许下载JDK的子集而不是一次下载整个平台，减少了下载量；允许在内存有限的设备如嵌入式控制器上安装JRE的一个子集。

Sun公司正在采取双管齐下的办法来构建JDK7的模块化特性：JSR 294和Jigsaw。JSR 294的主要目的是提高编译时和运行时环境之间的逼真度（fidelity）。这将增加语言功能来支持Java的模块系统，并更新目前需要类路径信息的重要组成部分，如javac和JVM本身。JSR 294最终将取消类路径。因为它独立于Jigsaw ，所以也可用于其他模块化系统，如OSGi ，甚至可以用于其他处理依赖关系的工具如谷歌的Guice或未来版本的JSR 299（Java的上下文和依赖注入） 。

Jigsaw将使用给JSR 294开发的部分特性，为Sun的JDK7实现构建模块系统。它是Sun JVM的一个实现细节 ，不会成为JSR的一个标准，而且技术上也不属于Java SE 。令人惊讶的是，Jigsaw与它打算取代的类路径，尽管是Java主机系统的事实标准，但都不属于Java语言规范。Sun已经创建了OpenJDK的一个开源子项目 ，也称为Jigsaw。该子项目将拥有JSR 294参考实现以及Jigsaw模块系统的设计与实现。

Alex Buckley在今年的JavaOne大会演讲上提供了一些JSR 294和Jigsaw如何工作的技术细节。其主要特征是引入了一个标准模块信息接口，Java程序可以使用它来指定依赖和其他细节。详细信息包括模块id，应用程序的主类，程序提供的模块和所依赖的模块。详细信息中还可包括版本信息（可选的），这会让Sun和开发者在将来易于修改已经被广泛使用的类库和API。一个来自Buckley的幻灯片的例子：

module org.planetjdk.aggregator @ 1.0 {
    system jigsaw;
    requires module jdom @ 1.*;
    requires module tagsoup @ 1.2.*;
    requires module rome @ =1.0;
    requires module rome-fetcher @ =1.0;
    requires module joda-time @ [1.6,2.0);
    requires module java-xml @ 7.*;
    requires module java-base @ 7.*;
    class org.planetjdk.aggregator.Main;
}
 

使用此模块信息，Jigsaw的打包工具（jpkg）能够创建一个映射部署文件，可以根据不同的平台而变化而且更紧密的与平台的能力相结合。这样Jigsaw将使得Java桌面应用在sun支持的各个平台上更加接近一等公民， 这是Sun振兴桌面Java所做努力的一个关键步骤。Mark Reinhold在JavaOne会议上演示了Jigsaw目前的一些能力，使用Linux的Synaptic Package Manager为一个简单的应用逐步建立需求，从一个基础的Java模块开始逐步增加额外的模块，如AWT和Swing 。

Sun决定兴建Jigsaw而不是使用现有的模块系统例如OSGi是非常有争议的， Sun并没有清楚的阐明为什么它已决定走这条路。在最近Java Posse的一个podcast中，Mark Reinhold和Alex Buckley也提供了一些关于两者分歧的技术细节，阐明了为什么Sun公司决定建立自己的系统。除了如同OSGi那样将打包的应用更多的绑定于平台之上，两个系统的依赖模型是不同的。Sun公司需要能够将包劈成不同的模块并将在运行时把它们加载到相同的类加载器中——例如java.util包可能被劈成不同的模块（甚至对有内存限制的装置有不同的实现）。为了支持这一特性Jigsaw有一个本地依赖的概念，该概念是递归的。所以，如果模块‘Swing’对于AWT有本地依赖而模块‘AWT’对于模块‘base’有一个本地依赖 ，那么在运行时模块Swing、AWT和base都将在同一类装载器中加载。虽然在OSG中的片段（frament）也是类似的概念，但不够更灵活，片段自己无法表达依赖性。

企业专家小组联席主席Eric Newcomer对此仍持怀疑态度。在最近的博客中，他把Jigsaw描述为“Sun重新发明OSGi的最新尝试，或在任何情况下阻挠OSGi或者建立他们能控制的OSGi替代品”，他继续写道：

“我今年没有参加JavaOne大会，所以可能由于我没有亲临而有错误的印象，但我的理解是，项目Jigsaw没有提到OSGi 。Java 7的计划说明也没有提到。因此，对于Jigsaw项目是否是对Java模块化的一个威胁这个问题，我的答案是，是的。”

其他一些博客被Sun的努力所打动，给出了积极的响应。其中Bram Bruneel对本地包生成留下了深刻的印象：

..Mark向我们展示了一个在Ubuntu上打包和分发Java应用的不错的演示 。JDK模块将会是标准的Debian软件包，您将能够创建自己的Java应用程序，导出为Debian软件包，并确定运行您的应用程序所需要的Java模块依赖。”

Alex Miller在他的文章中对Jigsaw的推崇是有见地的：

“项目目标是雄心勃勃的——在演示中有一个相当清晰的愿景，比我以前理解的要宽广得多。这个愿景包括对于我们如何编译、封装、启动我们的Java应用程序的全新方案。”

Glyn Normington听了Java Posse的podcast并写了评论：

“很高兴看到新出现的一些技术细节，我开始明白为什么OpenJDK选择与Apache的Harmony不同的模块化方案。”

Dalibor Topic对于本地打包工具的潜能特别感兴趣：

“语言概念的模块与实际模块系统的分离，可以让我们使用类似jpkg的工具来创建一个抽象模块到实际部署文件的N:M映射。为特定平台自由挑选其最好的发布机制有明显的好处，例如，在有一个软件包管理器的平台上，最友好的JDK发布方式是通过相应的软件包来发布。不用花大力气，通过提前编译转为平台所需要的本地化代码也成为可能：这一工作被转化为（在模块被封装为部署文件之前）可以应用于模块的另一个后期处理步骤，如在当前的jpkg代码中的pack200和LZMA压缩。将一个模块透明的分割为几个本地部署文件也变得很容易实现，例如，JNI库也可以转化为几个独立的、特定于架构的包，这样对于拥有多个架构本地代码的复杂应用，减少了下载量（顺便说一下，就像JDK一样）；同样，发布一个非常小的更新包来替换本地代码中一段有缓冲区溢出问题的代码片段也变得非常容易。”

查看英文原文：Jigsaw Falling Into Place