模块系统

　　模块系统的作用位于逻辑分离和物理分离之间。它强调模块分离，但各个模块仍然部署到同一个JVM中，而且模块间的通讯由简单传统的方法调用组成，因此不会有运行时的开支负担。在Java生态系统中最流行的模块框架是OSGi。它是一个成熟的规范，具有几个不同的实现。在OSGi中，模块被称作bundle，每个bundle等同于一个JAR。每个bundle也包含一个 META-INF/MANIFEST.MF文件，这个文件会宣布导出哪些包(package)以及导入哪些包。只有那些导出包中的类才能被其他 bundle所使用，而其他包都只面向包的内部成员，包里的类也只能在自身bundle中使用。

　　比如下面这个声明：

　　Manifest-Version: 1.0

　　Import-Package: net.krecan.spring.osgi.common

　　Export-Package: net.krecan.spring.osgi.dao

　　Bundle-Version: 1.0.0

　　Bundle-Name: demo-spring-osgi-dao

　　Bundle-SymbolicName: net.krecan.spring-osgi.demo-spring-osgi-dao

　　这个规范指定了名叫demo-spring-osgi-dao的bundle，它要导入包名为 net.krecan.spring.osgi.common中的类，并导出包名为net.krecan.spring.osgi.dao中的类。换句话说，这段声明表明其他模块只能使用net.krecan.spring.osgi.dao包。相反地，这个模块要使用的则只是 net.krecan.spring.osgi.common包，而且也可能会由OSGi来提供专门的模块负责导出这个包。当然你完全可以在导入和导出声明中定义多个包名。

　　需要特别注意的是，OSGi的模块化是构建在Java之上的。它不是语言的一部分!这里的模块分离虽然可以由GUI来执行，但不可以由编译器来执行。运行基于OSGi的应用时，你会需要一个OSGi的容器。这个容器可能是运行时环境的一部分，比如在Spring DM服务器中，也可能是嵌入在应用程序中的。这个容器不仅负责提供分离，也提供了其他诸如安全、模块管理和生命周期管理之类的服务。OSGi还提供大量其他有趣的特性，但这些并不是本文所要关注的。

　　关于JSR-277曾经有很多争议，这个JSR一度跟OSGi有部分重复。连续好几个月，双方的专家都极力辩论谁更优秀，直到JSR-277被宣布放弃，而新的模块系统将会是Java 7的一部分。

　　JSR-294

　　这个新的模块系统的第一部分就是JSR-294，即所谓的超级包。也正是这个规范阐释了Java语言的模块部分的概念。

　　JSR-294引入了新的可见性关键字“module”。如果一个成员拥有这样的可见性，那就意味着它只对同一模块中的成员可见。它会创建一个内部的 API，只有模块本身能调用。就此看来，“public”关键字应当只在声明一个公共的API时才用。而在其他情况下，应当使用“module”或者有更多限制的可见性关键字。当然，一旦语言中有了“module”关键字，那么模块之间的可见性限制将会由编译器来负责检查。

　　JSR-294也允许定义依赖性。你可以在某个给定版本中，定义某个模块依赖于另一模块。比如：

　　//org/netbeans/core/module-info.java

　　@Version("7.0")

　　@ImportModule(name="java.se.core", version="1.7+")

　　module org.netbeans.core;

　　最后一句表明“org.netbeans.core”模块依赖“java.se.core”的1.7版本或者更高。这类似于Maven的依赖性或者 OSGi的导入。你也可以暂时不要管这些语法，因为将来语法可能会另有变化。重要的是，这儿的依赖是在module-info.java中定义的，会被编译成class文件。而OSGi中，依赖则是在普通的文本文件中定义的。