对 Java 模块进行编译
现在进行下一步：编译我们的模块，并关联源文件。为了做这项工作，我们将介绍一个新的 javac 编译参数：
javac -modulesourcepath src -d mods $(find src -name '*.java')
使用上面语句时，我们假设命令程序已经处于 src 文件夹的上级目录中了。-modulesourcepath 参数会让 javac 从传统编译模式进入模块模式。-d 标记指出了编译好的模块的输出目录。javac 将以非打包文件的形式输出这些模块。如果我们这之后想以 jars 的形式使用这些模块的话，需要一个单独的步骤。
那么当我们调用上面的 javac 命令行的时候会发生什么那？编译出错了！
src/module1/module-info.java:1: error: expected 'module'
src/module2/module-info.java:1: error: expected 'module'
空的 module-info.java 文件导致了这个错误。所以，一些新的关键字将被引入到这些文件中来，这些都是模块中非常重要的部分。这些关键字的作用域就是 module-info.java 的定义部分。你还可以在 java 的源文件中使用 module 类型的变量。
我们采用了最少的描述信息，并更新了模块描述文件：
module module1 { }
然后是模块2：
module module2{ }
现在，模块已经被准确地命名了，但是还没有包含其它的数据。再次编译会导致新的错误：
src/module1/com/test/TestClassModule1.java:3: error: TestClassModule2 is not visible because package com.moretest is not visible
封装出现了！默认情况下，模块内部的类或者其他类型对外都是隐藏的。这就是 javac 不允许使用 TestClassModule2 的原因，即使它是一个公共的类。如果我们还是使用基于传统类路径的编译的话，一切都可以正常运作。当然我们也可以通过明确地将 TestClassModule2 暴露给外部来解决这个问题。接下来的这些改变对于 module2 中的 module-info.java 来说是必须的：
module module2 {
exports com.moretest;
}
这还不够。如果你将修改后的编译，你会得到同样的错误。那是因为，虽然现在 module2 已经暴露了所需的包（包含所有的公共类型），但是 module1 还没有声明它对 module2 的依赖。我们同样可以改变 module1 的 module-info.java 文件来解决这个问题：
module module1 {
requires module2;
}
通过指定名字的方法可以表示对其它模块的依赖，尽管在这些模块中是以包的形式导出的。这方面还有很多可以说的东西，但是我并不想在初步的介绍中涉及。在做完这一步之后，我们使用 Jigsaw 第一次成功编译了多模块项目。如果你打开 /mods 目录，你能看到编译出来的东西被整齐地划分为两个目录。这就成功了！
运行模块化代码
只是编译的话并没有多大乐趣。我们希望应用程序能够运行起来。幸运的是，JRE 和 JDK 已经在这个原型中支持模块关联。这个应用可以通过指定模块路径的方式来启动，而不是类路径：
java -mp mods -m module1/com.test.TestClassModule1
我们把模块路径指向 mods 文件夹，这个文件就是 javac 编译时写输出模块的地方。而 -m 指出了最初要启动的模块，通过这个模块可以逐步启动其他模块。我们同样添加了在初始化时需要调用的启动类的名字，运行结果如下所示：
Hi from from module 2!
未来
这部分介绍可以让你初步了解可以使用 Java 9 中的模块可以做什么。这部分还是需要更多的探索。就像打包一样：除了jar包，即将会有一种新的形式叫做 jmod 。这个模块化系统同样包括一个服务层，它可以通过接口绑定服务提供者和服务使用者。可以把这个看成反转控制：模块系统担任服务注册管理的角色。还有一个值得期待的地方是，JDK 本身将会如何使用模块化系统进行模块化。这有可能支持一些非常棒的技术，比如创建一个运行时镜像，这个镜像可以只包括 JDK 和你应用所需要的那些模块。好处有：占用更少的空间，对于程序整体的优化可以有更多的选择等等。这些前景都是很光明的。
我接下来将尝试移植一个简单的 OSGi 应用程序（该程序会使用一些模块和服务）到 Java 9 模块系统上。敬请关注！
