在过去几年，Java模块化一直是一个活跃的话题。从（现已废止）到，模块化看起来是Java进化过程中的必经一环。即便是基于JVM的未来语言，比如，也的问题。本文是关于模块化Java系列文章中的{dy}篇，讨论模块化的含义，以及为什么要xx它。
               
什么是模块化？

是个一般概念，这一概念也适用于软件开发，可以让软件按模块单独开发，各模块通常都用一个标准化的接口来进行通信。实际上，除了规模大小有区别外，面向对象语言中对象之间的xx点分离与模块化的概念基本一致。通常，把系统划分外多个模块有助于将减至{zd1}，让代码维护更加简单。

Java语言并不是按照模块化思想设计的（除了package，按照Java语言规范一 节的介绍，package类似于Modula-3模块），但是在Java社区依然有很多实际存在的模块。任何一个Java类库实际上都是一个模块，无论其 是Log4J、Hibernate还是Tomcat。通常，开源和非开源的应用都会依赖于一个或多个外部类库，而这种依赖关系又有可能传递到其他类库上。

类库也是模块

类库毫无疑问也是模块。对于类库来讲，可能没有一个单一接口与之通信，但往往却有‘’ API（可能被用到）和‘’ package（文档中说明了其用途）。此外，它们也有自己依赖的类库（比如或）。这将引起自动依赖管理器引入许多并非必须的类库：以为例，引入了超过10个依赖类库（包括javax.mail和javax.jms），尽管这些类库中有不少对于使用Log4J的程序来说根本不需要。

某些情况下，一个模块的依赖可以是可选的；换句话说，该模块可能有一个功能子集缺少依赖。在上面的例子中，如果JMS没有出现在运行时 classpath中，那么通过JMS记录日志的功能将不可用，但是其他功能还是可以使用的。（Java通过使用延迟链接——deferred linking来达到这一目的：直到要访问一个类时才需要其出现，缺少的依赖可以通过ClassNotFoundException来处理。其他一些平台的概念也是做类似的运行时检查。

通常，模块都附带一个版本号。许多开源项目生成的发行版都是以类似log4j-1.2.15.jar的方式命名的。这样开发者就可以在运行时通过手动方式来检测特定开源类库的版本。可是，程序编译的时候可能使用了另一个不同版本的类库：假定编译时用log4j-1.2.3.jar而运行时用log4j-1.2.15.jar，程序在行为上依然能够保持兼容。即使升级到下一个小版本，仍然是兼容的（这就是为什么log4j 1.3 的问题会导致一个产生，以表示兼容性被打破）。所有这些都是基于惯例而非运行时已知约束。

模块化何时能派上用场？

作为一般概念，模块化有助于将应用分解为不同的部件，各个部件可以单独测试（和开发）。正如上面所提到的，大多数类库都是模块。那么，对于那些生产类库提 供给别人使用的人来说，模块化是一个非常重要的概念。通常，依赖信息是在构建工具（maven pom 或 ivy-module）里进行编码并被明确记录在类库使用文档中的。另外，高层类库开发过程中需要修改较低层级类库bug，以提供更好支持的情况并不少 见，即便低层类库的{zx1}版本已经对bug进行了修正。（可是有时候这种情况。

如果一个类库是提供给他人使用的，那么它就已经是一个模块了。但是世上鲜有“Hello World”这样的类库，也鲜有“Hello World”这样的模块。只有当应用足够大时（或者是用一个模块化构建系统进行构建时），把应用划分为不同部件的概念就派上用场了。

模块化的好处之一是便于测试。一个小模块（具有定义良好的API）通常比应用整体更好测试。在GUI应用中尤其如此，GUI自身可能不好测试，但是其调用的代码却是可测试的。

模块化的另一个好处是便于进化。尽管系统整体有一个版本号，但实际上，其下有多个模块及相应版本（不论开源与否，总有一些类库——甚至是Java版本—— 是系统所依赖的）。这样，每个模块都可以自己的方式自由地进化。某些模块进化得快些，另一些则会长期保持稳定（例如，Eclipse 3.5 的org.eclipse.core.boot从2008年2月以来一直没有改变过）。

模块化也可给项目管理带来方便。如果一个模块公布的API可供其他模块预先使用，那么各个模块就可以由不同的团队分别开发。这在大型项目中必定会发生，各个项目子团队可以负责不同模块的交付。

{zh1}，将一个应用程序模块化，可以帮助识别正在使用依赖类库的哪个版本，以便协调大型项目中的类库依赖。