模块化是大型Java系统的一个重要特征。在这些项目中构建脚本和项目通常被划分为 多个模块，以便改进构建过程，但是在运行时却很少考虑划分模块的问题。
在“模块化Java”系列文章的第二篇里，我们将讨论静态模块化（static modularity ）。内容包括如何创建bundle、将其安装到OSG引擎以及怎样建立bundle之间的版本依赖 。在下一篇文章中，我们将讨论动态模块化（dynamic modularity）并展示bundle如何对 其他bundle作出响应。
在上篇文章《模块化Java简介》中讲到，Java在开发时把package作为模块化单元，部 署时把JAR文件作为模块化单元。可是尽管像Maven这样的构建工具能够在编译时保证 package和JAR的特定组合，但这些依赖在运行时classpath下仍可能出现不一致的情况。 为了解决这一问题，模块可以声明其依赖需求，这样，在运行时就可以在执行之前进行依 赖检查。
OSGi是一个Java的运行时动态模块系统。OSGi规范描述了OSGi运行时的工作行为方式 ；当前版本是OSGi R4.2。
一个OSGi模块（也称为bundle）就是一个普通的JAR文件，但在其MANIFEST.MF中带有 附加信息。一个bundle的manifest必须至少包含如下内容：
Bundle-ManifestVersion：对OSGi R4 bundle来说必须是2（OSGi R3 bundle则默认为 1）
Bundle-SymbolicName：bundle的文本标识符，通常以反向域名的形式出现，如 com.infoq，并且往往对应了包含其中的package
Bundle-Version：major.minor.micro.qualifier形式的版本号，前三个元素是数字（ 缺省是0），qualifier则是文本（缺省是空字符串）
创建一个bundle
最简单的bundle必须在manifest文件中包含如下内容：
Bundle-ManifestVersion: 2Bundle-SymbolicName: com.infoq.minimalBundle-Version: 1.0.0
创建bundle并没有什么可稀奇的，那么让我们创建一个带activaTor的bundle吧。下面 是OSGi特定的代码片段，在bundle启动时被调用，有点像是bundle的main方法。
package com.infoq;import org.osgi.framework.*;public class ExampleActivaTor implements BundleActivaTor { public void start(BundleContext context) { System.out.println("Started"); } public void stop(BundleContext context) { System.out.println("Stopped"); }}
为了让OSGi知道哪个类是activaTor，我们需要在manifest中加入额外的信息项：
Bundle-ActivaTor: com.infoq.ExampleActivaTorImport-Package: org.osgi.framework
Bundle-ActivaTor声明了在bundle启动时要实例化并调用其start()方法的类；类似的 ，在bundle停止时将调用该类的stop()方法。
那么Import-Package又是干什么的？每个bundle都需要在manifest中定义其依赖，以 便在运行时判断所有必需代码是否可用。在本例中，ExampleActivaTor依赖于 org.osgi.framework包中的BundleContext；如果我们不在manifext中声明该依赖，在运 行时就会碰到NoClassDefFoundError错误。
下载OSGi引擎
要编译并测试我们的bundle，需要一个OSGi引擎。对OSGi R4.2，下面罗列了几个可用 的开源引擎。你也可以下载Reference API来编译（这样可以确保没有用到任何平台特定 特性）；可是，要运行bundle，还是需要一个OSGi引擎。以下引擎都可供选择：
Equinox 许可 Eclipse Public License 文献 http://www.eclipse.org/equinox/ 下载 org.eclipse.osgi_3.5.0.v20090520.jar 评注 该org.eclipse.osgi bundle包含了框架、运行时和shell，是全部合一的。它 的文件名也最长，用tab补全（或改名为equinox.jar）可以解决这一问题。 要启动console，在命令行输入java -jar org.eclipse.osgi_3.5.0.v20090520.jar -console即可。 框架 org.eclipse.osgi_3.5.0.v20090520.jar Felix 许可 Apache License 文献 http://felix.apache.org/ 下载 Felix Framework Distribution 2.0.0 评注 这是所见遵守规范最严格的OSGi引擎，还被用在GlassFish及许多其他开源产 品中。运行时需要在命令行输入java -jar bin/felix.jar而不是 java -jar felix.jar ，因为启动时它要从当前目录查找bundles 路径。 框架 bin/felix.jar Knopflerfish 许可 Knopflerfish License (BSD-esque) 文献 http://www.knopflerfish.org/ 下载 knopflerfish_fullbin_osgi_2.3.3.jar 评注 该JAR是一个自解压zip文件；刚开始你必须运行java -jar进行解压。不要下 载“bin_osgi”，它无法启动。 框架 knopflerfish.org/osgi/framework.jar另外还有更小的定位于嵌入设备的OSGi R3运行时可用（比如Concierge），但本系列 文章只关注OSGi R4。
编译并运行bundle
获得framework.jar之后，把OSGi加入classpath并编译上面的例子，然后将其打包成 JAR：
javac -cp framework.jar com/infoq/*/*.javajar cfm example.jar MANIFEST.MF com
每种引擎都有shell，命令也相似（但不相同）。为了便于练习，让我们看看如何获得 这些引擎并使之运行、安装和启/停bundle。
一旦引擎启动并运行起来，你就可以安装bundle（由 file:// URL来定位）了，然后 可以使用安装bundle所返回的bundle id，启动或停止该bundle。
Equinox Felix Knopflerfish 启动应用 java -jar org.eclipse.osgi_*.jar -console java -jar bin/felix.jar java -jar framework.jar -xargs minimal.xargs 帮助 help 列表 ss ps bundles 安装 install file:///path/to/example.jar 启动 start id 更新 update id 停止 stop id 卸载 uninstall id 退出 exit shutdown尽管所有的shell工作起来大都一样，但命令之间还是有容易混淆的细微差别。有两个 统一console的项目（Pax Shell，Posh）和运行器（Pax Runner）可以利用；OSGi RFC 132则是一个正在进行中的提案，试图标准化command shell。另外，Apache Karaf可以运 行在Equinox或Felix之上，提供统一的shell以及其他特性。尽管使用这些项目或工具进 行实际部署是可取的，但本系列文章还是关注于普通的OSGi框架实现。
如果你启动了OSGi框架，你应该能够安装上面所讲的com.infoq.minimal-1.0.0.jar（ 你还可以用链接地址及install命令直接从网站上进行安装）。每次安装bundle，引擎都 会打印出该bundle的数字ID。
在安装好bundle之前不可能知道bundle的ID是多少，这取决于系统中其它bundle的ID 分配情况；但是你可以使用适当的命令罗列出已安装的bundle将其找出来。
依赖
迄今为止，我们只有一个bundle。模块化的一个好处是可以把系统分解为多个小模块 ，在此过程中，减小应用的复杂性。从某种程度上，Java的 package已经做到了这一点： 例如，一个common包有独立的client和server包，他们都依赖于该common包。但是Jetty 最近的例子（client意外地依赖于server）表明做到这一点并不总是很容易。实际上，有 些由OSGi给项目带来的好处纯粹就是强制模块间的模块化约束。
模块化的另一个好处是把’public’包从非public包中分离出来。Java的编译时系统允 许隐藏非public类（在特定包中是可见的），但是不支持更大程度的灵活性。然而在OSGi 模块中，你可以选择哪些包是exported（输出）的，这就意味着没有输出的包对其他模块 是不可见的。
让我们继续开发一个功能，用来初始化URI Templates（与Restlet中使用的一样）。 因为该功能可重用，我们想将其放在一个单独模块中，让使用它的客户端依赖于它。（通 常，bundle不适合这么细粒度的用法，但是其可用于说明工作原理）。该功能将根据一个 模板（比如http://www.amazon.{tld}/dp/{isbn}/）和一个包含有 tld=com,isbn=1411609255的Map，产生出URL http://www.amazon.com/dp/1411609255/（ 这么做的一个原因是，如果Amazon URL模式发生了变化，我们能够改变该模板，尽管好的 URI是不会改变的）。
为了提供一个在不同实现之间切换的简单方法，我们将提供一个接口和一个工厂。这 会让我们看到在提供功能的同时实现是怎样对client隐藏的。代码（对应几个源文件）如 下：
package com.infoq.templater.api;import java.util.*;public interface ITemplater { public String template(String uri, Map data);}// ---package com.infoq.templater.api;import com.infoq.templater.internal.*;public class TemplaterFacTory { public static ITemplater getTemplater() { return new Templater(); }}// ---package com.infoq.templater.internal;import com.infoq.templater.api.*;import java.util.*;public class Templater implements ITemplater { public String template(String uri, Map data) { String[] elements = uri.split("//{|//}"); StringBuffer buf = new StringBuffer(); for(int i=0;i
该实现隐藏在com.infoq.templater.internal包中，而public API则位于 com.infoq.templater.api包中。这就给了我们巨大的灵活性，如果需要，以后可以修改 实现以提供更加有效的手段。（internal包名是约定俗成，你可以起其他名字）。
为了让其他bundle能够访问该public API，我们需要将其export（输出）。我们的 manifest如下：
Bundle-ManifestVersion: 2Bundle-SymbolicName: com.infoq.templaterBundle-Version: 1.0.0Export-Package: com.infoq.templater.api
创建一个client bundle
我们现在可以创建一个使用templater的client。利用上面的例子创建一个activaTor ，其start()方法如下：
package com.infoq.amazon;import org.osgi.framework.*;import com.infoq.templater.api.*;import java.util.*;public class Client implements BundleActivaTor { public void start(BundleContext context) { Map data = new HashMap(); data.put("tld", "co.uk"); // or "com" or "de" or ... data.put("isbn", "1411609255"); // or "1586033115" or ... System.out.println( "Starting/n" + TemplaterFacTory.getTemplater().template( "http://www.amazon.{tld}/dp/{isbn}/", data)); } public void stop(BundleContext context) { }}
我们需要在manifest中显式输入templater API，否则我们的bundle无法编译。用 Import-Package或Require-Bundle都可指定依赖。前者可以让我们单独输入包；后者则将 隐式输入该bundle中所有输出包。（多个包及bundles可以用逗号分开）。
Bundle-ManifestVersion: 2Bundle-SymbolicName: com.infoq.amazonBundle-Version: 1.0.0Bundle-ActivaTor: com.infoq.amazon.ClientImport-Package: org.osgi.frameworkRequire-Bundle: com.infoq.templater
注意在前面的例子中，我们已经使用了Import-Package来输入org.osgi.framework。 在这个例子中，我们将演示 Require-Bundle的用法，其使用了Bundle-SymbolicName。当 然，用Import-Package: org.osgi.framework, com.infoq.templater.api可以达到相同 的效果。
不管如何声明依赖于templater的bundle，我们都只能访问单一的输出包 com.infoq.templater。尽管client可以通过 TemplaterFacTory.getTemplater()来访问 templater，但是我们不能直接从internal包中访问该类。这样我们在未来就可以在不影 响client的情况下改变templater类的实现。
测试该系统
任何OSGi应用实际上都是一组bundle。在本例中，我们需要编译并把bundle打包为JAR （如前面所述），启动OSGi引擎，安装两个bundle。下面是在Equinox中进行操作的例子 ：
java -jar org.eclipse.osgi_* -consoleosgi> install file:///tmp/com.infoq.templater-1.0.0.jarBundle id is 1osgi> install file:///tmp/com.infoq.amazon-1.0.0.jarBundle id is 2osgi> start 2Starting http://www.amazon.co.uk/dp/1411609255
Amazon client bundle现在已经启动了；当其启动时，它先用（硬编码的）给定值为 我们初始化URI template。然后在该bundle启动过程中打印出来以确定其已正常工作。当 然，一个真正的系统不会这么死板；但是Templater服务可以用于任何其他应用（例如， 产生一个基于Web的应用中的链接）。将来，我们将能够在OSGi环境中查看Web应用。
带版本的依赖
本文最后要指出的是目前我们所谈的依赖都没有版本；更确切的说，我们可以使用任 意版本。两个bundle整体及各个包都可以有版本，增大minor 号通常 意味着增加了新特 性（但保持向后兼容）。以org.osgi.framework包为例，OSGi R4.1中是1.4.0，OSGi R4.2中是1.5.0。（顺便提一句，这是bundle版本和销售版本保持分离的很好理由，Scala 语言已经这么做了）。
要声明依赖处于一个特定版本，我们必须在Import-Package或Require-Bundle中来表 达。比如，我们可以指定 Require- Bundle: com.infoq.templater;bundle- version=”1.0.0″以表示工作所需的最低版本为1.0.0。类似的，我们可以用 Import- Package: com.infoq.templater.api;version=”1.0.0″做相同的事情 —— 但是要记住 package与bundle版本是完全分开的。如果你不指定版本，缺省为0.0.0，因此，除非指定 了相应的Export-Package: com.infoq.templater.api;version=”1.0.0″否则该输入不会 被解析。
还可以指定一个版本范围。例如，按惯例OSGi版本的major号增大表示向后兼容发生改 变，因此我们可能想将其限制在1.x的范围内。我们可以通过 (bundle-) version=”[1.0,2.0)”的方式来表达这一依赖约束。该例中，[表示‘包含’，而)表示‘ 不包含’。换句话说，‘从 1.0到2.0但不包括2.0’。实际上，将一个依赖约束表达为‘ 1.0’与“[1.0,∞)”意思是一样的——换句话说，比1.0版高都可以。
尽管这些内容超出了本文的范围，但是在一个OSGi系统中，一个bundle同时有两个版 本也是可能的。如果你有一个老client依赖于1.0版本 API，同时又一个新client依赖于 2.0版本API，这就非常有用了。只要每个bundle的依赖是一致的（换句话说，一个bundle 不能直接或间接同时输入1.0和2.0）那么应用程序将工作良好。作为读者练习，你可以创 建一个使用泛型的2.0版的Templater API，然后让一个client依赖于1.x，而另一个依赖 于2.x。
总结
在本文中，我们探讨了开源OSGi引擎Equinox、Felix和Knopflerfish，并且创建了两 个有依赖关系的bundle。我们还谈到了带版本的依赖。截止目前，模块化还是静态的；我 们还没有涉及到OSGi的动态本质。在下一篇文章中我们将涉及这一内容。
带着感恩的心启程，学会爱，爱父母，爱自己，爱朋友，爱他人。
