模块化Java简介

核心提示： 除了作为整体的rt.jar之外，任何其他系统都可以被分解为不同的模块，模块化Java简介(5)，问题是这么做是否值得？毕竟，从头构建一个模块化系统比起把一个单模块系统分割成多个模块要容易得多，也面临依赖链和版本问题，由于（特定）plugin API演化的复杂性，之所以这样，原因之一是跨越模块边界

除了作为整体的rt.jar之外，任何其他系统都可以被分解为不同的模块。问题是这么做是否值得？毕竟，从头构建一个模块化系统比起把一个单模块系统分割成多个模块要容易得多。

之所以这样，原因之一是跨越模块边界的类泄漏。例如，java.beans包逻辑上不应该依赖于任何GUI代码；可是Beans.instantiate()所使用的java.beans.AppletInitializer引用了Applet，这必然导致对整个AWT的依赖。因此从技术上讲java.beans有依赖于AWT的选项，尽管常识告诉我们不应该有。如果核心java类库从一开始就采用了模块化方法来构建，那么这种错误早在API公布之前就发现了。

有些情况下，一个模块看上去不能再被划分成子模块了。可是，有时候相关功能保持在同一个模块中是为了便于组织，当需要的时候还可以再进一步分解。例如，对重构的支持起初是Eclipse JDT的一部分，现在被抽出为一个模块，以便其他语言（如CDT）利用其重构能力。

Plugins

许多系统都是通过plugin概念进行扩展的。在这种情况下，宿主系统定义了一套plugin必须遵循的API及plugin注入方式。许多应用（如Web浏览器、IDE及构建工具）通常都是通过提供带有适当API的插件来对应用进行定制的。

有时候这些plugin受到限制或只有一些普通操作（音频或视频解码），但是组织起来效果也非常不错（例如，IDE的众多plugin）。有时候，这些 plugin可以提供自己的plugin，以便进一步定制行为，使得系统具有更高可定制性。（可是，增加这些中间层级会使系统难以理解。）

这种plugin API成为各个plugin必须遵守的契约的一部分。这些plugin自己也是模块，也面临依赖链和版本问题。由于（特定）plugin API演化的复杂性，因此plugin自己也面临这一问题（必须维持向后兼容性）。