几个不 同的实现。在 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 文