模块化Java简介

核心提示： Netscape plugin API成功的原因之一是其简单性：只需实现少量的函数，只要宿主浏览器用适当的MIME类型将输入重定向，模块化Java简介(6)，plugin就可以处理其他事情，可是，其可以完全在Java语言规范中被定义，以便Java开发者可以产生带有编码依赖信息的标定过版本的模块，

Netscape plugin API成功的原因之一是其简单性：只需实现少量的函数。只要宿主浏览器用适当的MIME类型将输入重定向，plugin就可以处理其他事情。可是，更复杂的应用（如IDE）通常需要更紧密集成各个模块，因此需要一个更复杂的API来推动。

Java模块化的当前状态

目前，Java领域存在许多模块化系统和plugin体系。IDE是名气最大的，IntelliJ、NetBeans和Eclipse都提供了其自己的 plugin系统作为其定制途径。而且，构建系统（Ant、Maven）甚至终端用户应用（Lotus Notes、Mac AppleScript应用）都有能够扩展应用或系统核心功能的概念。

OSGi是Java领域里无可辩驳的最成熟的模块系统，它与Java几乎是如影相随，最早出现于JSR 8，但是最新规范是JSR 291。 OSGi在JAR的MANIFEST.MF文件中定义了额外的元数据，用来指明每个包所要求的依赖。这就让模块能够（在运行时）检查其依赖是否满足要求，另外，可以让每个模块有自己的私有 classpath（因为每个模块都有一个ClassLoader）。这可以让dependency hell尽早被发现，但是不能完全避免。和JDBC一样，OSGi也是规范（目前是4.2版），有多个开源（及商业）实现。因为模块不需要依赖任何OSGi的特定代码，许多开源类库现在都将其元信息嵌入到manifest中，以便OSGi运行时使用。有些程序包没有这么做，也可以用bnd这样的工具，它可以处理一个已有的JAR文件并为其产生合适的默认元信息。自2004年Eclipse 3.0 从专有plugin系统切换到OSGi之后，许多其他专有内核系统（JBoss、WebSphere、Weblogic）也都随之将其运行时转向基于OSGi内核。

最近创建的Jigsaw项目是为了模块化JDK自身。尽管其是JDK内部的一部分，并且很可能在其他SE 7 实现中不被支持，但是在该JDK之外使用Jigsaw并无限制。尽管仍在开发当中，Jigsaw还很可能成为前面提到的JSR 294的参考实现。最低要求SE 7（加上目前还没有Java 7的事实）说明了Jigsaw仍在开发中，而且运行在Java 6或更低版本上的系统基本上是用不上了。

为了鼓励采用标准模块化格式，JSR 294专家组目前正在讨论简单模块系统提议：在这一提议中，Java类库（来自Maven库及Apache.org）的开发者能够提供让Jigsaw和OSGi系统都能使用的元信息。结合对Java语言的微小变动（最值得关注的是增加的module关键字），这一信息可以在编译时由高级编译器产生。运行时系统（如Jigsaw或OSGi）可以使用这些信息来校验所安装的模块及其依赖。

总结

本文讨论了模块化的一般概念，以及在Java系统中是如何实现的。由于编译时和运行时路径可能不同，有可能会产生不一致的类库需求，从而导致依赖地狱。然 而，plugin API允许装载多种代码，但其必须遵循宿主的依赖处理规则，这又增加了发生不一致的可能性。为了防止这种情况出现，像OSGi这样的运行时模块化系统可以在决定应用是否能被正确启动之前就校验各项要求，而不是在运行时不知不觉发生错误。

最后，有人在正在进行中的JSR 294的邮件列表中提出，要为Java语言创建一个模块系统，其可以完全在Java语言规范中被定义，以便Java开发者可以产生带有编码依赖信息的标定过版本的模块，该模块以后可以用于任何模块系统。