件。而 OSGi 中，依赖则是在普通的文本文件中定义的。

Jigsaw 项目
　　Jigsaw 项目是这个新模块系统的第二部分。我预计它会是 JSR-294 特定于 Sun 的实现，
 也会是 Sun JDK 的模块化实现。既然创建完整的 JDK 模块化是有必要的，Sun 就希望把
标准库分装成模块。这直接简化了 JRE 中的内容整合。整个 JRE

 

除了 Swing 之外的所有内

容因此都能够在移动设备上运行。它还有可能为语言引入新的标准 API，而无需再等待整

 

个平台的新版本发布。目前看起来，这个项目绝 对有希望实现。
　　但我对此还有个担忧，那就是，a href="http://blogs.sun.com/mr/entry/jigsaw">专有的
Jigsaw 和 JSR 标准之间的关系并不清晰，正如 Mark Reinhold 所说的：

 

　 　对 Jigsaw 的投入无疑会创建出一个简单的、低层次的模块系统，它的设计会严格地
朝着 JDK

 

模块化的目标而发展。开发人员可以把这个模块系统运用到他 们的代码中去 ，

Sun 对这个模块系统也会是绝对的支持，但它不会是 Java SE 7 平台规范的官方部分，也
可能不会被其他 SE 7 实现所支持。

 

　 　这段话说的不是很清楚，当中有很多疑问。他的意思是说创建的模块只能在 Sun JRE
中 运 行 吗 ?

“

还 是 想 说 ， 如 果 开 发 者 写 了

@ImportModule(name="java.se.core", 

version="1.7+")”，那么这个模块只能在 Sun JRE 中运行，而不能在 IBM JRE 环境中运行
吗?或者他的意思是不是说 Sun 会以某种方式把它的 JRE 分割成许多模块，而 Oracle 会选
择另外的方式去分割吗?(

 

译者注：至少现在 看来，不太会有这样的可能了，因为 Oracle

刚刚收购了 Sun)

“

”

。我们希望都不是，因为还有 编写一次，到处运行 的原则。

　　细究起来问题更多。我们并不清楚 Jigsaw 项目的主要目标是什么。据项目本身所宣布
的主要目标来看，它要实现的是 Sun JRE 的模块化，但如果纯粹是要实现模块化的话，
就不需要对语言做任何改变。Sun 可以对 JRE 进行模块化，而不修改 Java 语言本身。
　　这些语言上的变化会不会成为 Sun JRE 模块化带来的副产品?如果是，那就彻底错了!
语言变化必须是一等公民，而不是专属的副产品。
　依赖
　　我的另外一个担心在于依赖性。如果依赖性由模块系统来管理，那就不再需要
classpath

 

了。一方面这很 不错，因为 classpath 经常会导致所谓的 JAR 地狱问题。但另一方

面，classpath

 

也是极度灵活的，我恐怕这种灵活性是不可能由一个静态的模 块依赖能够

拥有的。让我们来看看为什么：
　　部署时依赖
　　Java 中有两种类路径(classpath)。一个是构建路径(buildpath)，它用在构建时。另外一个
是类路径，用在运行时。两者几乎相同，但又不完全是。经典的例子就是 JDBC 驱动  

。在构

建时，你不需要指定 JDBC 驱动，JDBC 接口是 Java 核心库的一部分。但在运行时，你就
有必要确保类路径中有 JDBC

 

的驱动。如果某个编程人员需 要修改数据库连接，他只需要

在配置文件中修改驱动类的名称，并把驱动 jar 文件添加到类路径就可以了。如果所有的

 

依赖需要在编译时指定，开发者很明显无法 做到这点。当然，在 Java EE 中，他可以使用
JNDI 数据源，但在 Java SE 中没有类似的东西，一旦修改 JDBC 驱动，就不得不重新编译
整个应用，这明显很不靠谱。
　　通常来说，重新编译不太可能。在一些组织中，最终的应用是由所谓的应用装配器的
模块组装而成的。开发者没有源代码，他只是把一些 JAR 放在一起，修改一下配置文件，
然后创建最终的包。应用装配器的角色甚至在 Java EE 的规范中都有提到。