在過去幾年，Java模塊化一直是一個活躍的話題。從JSR 277（現已廢止）到JSR 291 ，模塊化看起來是Java進化過程中的必經一環。即便是基於JVM的未來語言，比如Scala， 也考慮了模塊化的問題。本文是關於模塊化Java系列文章中的第一篇，討論模塊化的含義 ，以及為什麼要關注它。
什麼是模塊化？
模塊化是個一般概念，這一概念也適用於軟件開發，可以讓軟件按模塊單獨開發，各 模塊通常都用一個標准化的接口來進行通信。實際上，除了規模大小有區別外，面向對象 語言中對象之間的關注點分離與模塊化的概念基本一致。通常，把系統劃分外多個模塊有 助於將耦合減至最低，讓代碼維護更加簡單。
Java語言並不是按照模塊化思想設計的（除了package，按照Java語言規范 introduction一節的介紹，package類似於Modula-3模塊），但是在Java社區依然有很多 實際存在的模塊。任何一個Java類庫實際上都是一個模塊，無論其是Log4J、Hibernate還 是Tomcat。通常，開源和非開源的應用都會依賴於一個或多個外部類庫，而這種依賴關系 又有可能傳遞到其他類庫上。
類庫也是模塊
類庫毫無疑問也是模塊。對於類庫來講，可能沒有一個單一接口與之通信，但往往卻 有‘public’ API（可能被用到）和‘private’ package（文檔中說明了其用途）。此 外，它們也有自己依賴的類庫（比如JMX或JMS）。這將引起自動依賴管理器引入許多並非 必須的類庫：以Log4J-1.2.15為例，引入了超過10個依賴類庫（包括javax.mail和 javax.jms），盡管這些類庫中有不少對於使用Log4J的程序來說根本不需要。
某些情況下，一個模塊的依賴可以是可選的；換句話說，該模塊可能有一個功能子集 缺少依賴。在上面的例子中，如果JMS沒有出現在運行時 classpath中，那麼通過JMS記錄 日志的功能將不可用，但是其他功能還是可以使用的。（Java通過使用延遲鏈接—— deferred linking來達到這一目的：直到要訪問一個類時才需要其出現，缺少的依賴可以 通過ClassNotFoundException來處理。其他一些平台的弱鏈接——weak linking概念也是 做類似的運行時檢查。）
通常，模塊都附帶一個版本號。許多開源項目生成的發行版都是以類似log4j- 1.2.15.jar的方式命名的。這樣開發者就可以在運行時通過手動方式來檢測特定開源類庫 的版本。可是，程序編譯的時候可能使用了另一個不同版本的類庫：假定編譯時用log4j -1.2.3.jar而運行時用log4j-1.2.15.jar，程序在行為上依然能夠保持兼容。即使升級到 下一個小版本，仍然是兼容的（這就是為什麼log4j 1.3 的問題會導致一個新分支2.0產 生，以表示兼容性被打破）。所有這些都是基於慣例而非運行時已知約束。
模塊化何時能派上用場？
作為一般概念，模塊化有助於將應用分解為不同的部件，各個部件可以單獨測試（和 開發）。正如上面所提到的，大多數類庫都是模塊。那麼，對於那些生產類庫提 供給別 人使用的人來說，模塊化是一個非常重要的概念。通常，依賴信息是在構建工具（maven pom 或 ivy-module）裡進行編碼並被明確記錄在類庫使用文檔中的。另外，高層類庫開 發過程中需要修改較低層級類庫bug，以提供更好支持的情況並不少見，即便低層類庫的 最新版本已經對bug進行了修正。（可是有時候這種情況可能會導致出現一些微妙的問題 。）
如果一個類庫是提供給他人使用的，那麼它就已經是一個模塊了。但是世上鮮有 “Hello World”這樣的類庫，也鮮有“Hello World”這樣的模塊。只有當應用足夠大時 （或者是用一個模塊化構建系統進行構建時），把應用劃分為不同部件的概念就派上用場 了。
模塊化的好處之一是便於測試。一個小模塊（具有定義良好的API）通常比應用整體更 好測試。在GUI應用中尤其如此，GUI自身可能不好測試，但是其調用的代碼卻是可測試的 。
模塊化的另一個好處是便於進化。盡管系統整體有一個版本號，但實際上，其下有多 個模塊及相應版本（不論開源與否，總有一些類庫——甚至是Java版本—— 是系統所依 賴的）。這樣，每個模塊都可以自己的方式自由地進化。某些模塊進化得快些，另一些則 會長期保持穩定（例如，Eclipse 3.5 的org.eclipse.core.boot從2008年2月以來一直沒 有改變過）。
模塊化也可給項目管理帶來方便。如果一個模塊公布的API可供其他模塊預先使用，那 麼各個模塊就可以由不同的團隊分別開發。這在大型項目中必定會發生，各個項目子團隊 可以負責不同模塊的交付。
最後，將一個應用程序模塊化，可以幫助識別正在使用依賴類庫的哪個版本，以便協 調大型項目中的類庫依賴。
運行時與編譯時
無論在編譯時還是運行時，Java的classpath都是扁平的。換句話說，應用程序可以看 到classpath上的所有類，而不管其順序如何（如果沒有重復，是這樣；否則，總是找最 前面的）。這就使Java動態鏈接成為可能：一個處於classpath前面的已裝載類，不需要 解析其所引用的可能處於 classpath後面的那些類，直到確實需要他們為止。
如果所使用的接口實現到運行時才能清楚，通常使用這種方法。例如，一個SQL工具可 以依賴普通JDBC包來編譯，而運行時（可以有附加配置信息）可以實例化適當的JDBC驅動 。這通常是在運行時將類名（實現了預定義的工廠接口或抽象類）提供給Class.forName 查找來實現。如果指定的類不存在（或者由於其他原因不能加載），則會產生一個錯誤。
因此，模塊的編譯時classpath可能會與運行時classpath有些微妙的差別。此外，每 個模塊通常都是獨立編譯的（模塊A可能是用模塊C 1.1 來編譯的，而模塊B則可能是用模 塊C 1.2 來編譯的），而另一方面，在運行時則是使用單一的路徑（在本例中，即可能是 模塊C的1.1版本，也可能是1.2版本）。這就會導致依賴地獄（Dependency Hell），特別 當它是這些依賴傳遞的末尾時更是這樣。不過，像Maven和Ivy這樣的構建系統可以讓模塊 化特性對開發者是可見的，甚至對最終用戶也是可見的。
Java有一個非常好的底層特性，叫做ClassLoader，它可以讓運行時路徑分得更開。通 常情況下，所有類都是由系統ClassLoader裝載的；可是有些系統使用不同的ClassLoader 將其運行時空間進行了劃分。Tomacat(或者其他Servlet引擎)就是一個很好的例子，每個 Web應用都有一個ClassLoader。這樣Web應用就不必去管（無論有意與否）在同一JVM中其 他Web應用所定義的類。
這種方式下，每個Web應用都用自己的ClassLoader裝載類，這樣一個（本地）Web應用 實現裝載的類不會與其他Web應用實現相沖突。但這就要 求對任何ClassLoader鏈，類空 間都是一致的；這意味著在同一時刻，你的VM可以同時從兩個不同的Classloader中各自 裝載一個Util.class，只要這兩個ClassLoader互相不可見。（這也是為什麼Servlet引擎 具有無需重啟即可重新部署的能力；扔掉了一個ClassLoader，你也就扔掉了其引用類， 讓老版本符合垃圾回收的條件——然後讓Servlet引擎創建一個新的ClassLoader並在運行 時中重新部署應用類的新版本。）
再談模塊
構建一個模塊化系統實際上是把系統劃分成（有可能）可重用模塊的過程，並使模塊 間耦合最小化。同時，其也是一個減少模塊需求耦合的過程：例如，Eclipse IDE許多 plugin對GUI和非GUI組件（如jdt.ui和jdt.core）的依賴是分開的，這樣就可以在IDE環 境之外使用這些非GUI模塊（headless builds、分析及錯誤檢查等等）。
除了作為整體的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自己也 面臨這一問題（必須維持向後兼容性）。
Netscape plugin API成功的原因之一是其簡單性：只需實現少量的函數。只要宿主浏 覽器用適當的MIME類型將輸入重定向，plugin就可以處理其他事情。可是，更復雜的應用 （如IDE）通常需要更緊密集成各個模塊，因此需要一個更復雜的API來推動。
Java模塊化的當前狀態
目前，Java領域存在許多模塊化系統和plugin體系。IDE是名氣最大的，IntelliJ、 NetBeans和Eclipse都提供了其自己的 plugin系統作為其定制途徑。而且，構建系統 （Ant、Maven）甚至終端用戶應用（Lotus Notes、Mac AppleScript應用）都有能夠擴展 應用或系統核心功能的概念。
OSGi是Java領域裡無可辯駁的最成熟的模塊系統，它與Java幾乎是如影相隨，最早出 現於JSR 8，但是最新規范是JSR 291。 OSGi在JAR的MANIFEST.MF文件中定義了額外的元 數據，用來指明每個包所要求的依賴。這就讓模塊能夠（在運行時）檢查其依賴是否滿足 要求，另外，可以讓每個模塊有自己的私有 classpath（因為每個模塊都有一個 ClassLoader）。這可以讓dependency hell盡早被發現，但是不能完全避免。和JDBC一樣 ，OSGi也是規范（目前是4.2版），有多個開源（及商業）實現。因為模塊不需要依賴任 何OSGi的特定代碼，許多開源類庫現在都將其元信息嵌入到manifest中，以便OSGi運行時 使用。有些程序包沒有這麼做，也可以用bnd這樣的工具，它可以處理一個已有的JAR文件 並為其產生合適的默認元信息。自2004年Eclipse 3.0 從專有plugin系統切換到OSGi之後 ，許多其他專有內核系統（JBoss、WebSphere、Weblogic）也都隨之將其運行時轉向基於 OSGi內核。
最近創建的Jigsaw項目是為了模塊化JDK自身。盡管其是JDK內部的一部分，並且很可 能在其他SE 7 實現中不被支持，但是在該JDK之外使用Jigsaw並無限制。盡管仍在開發當 中，Jigsaw還很可能成為前面提到的JSR 294的參考實現。最低要求SE 7（加上目前還沒 有Java 7的事實）說明了Jigsaw仍在開發中，而且運行在Java 6或更低版本上的系統基本 上是用不上了。
為了鼓勵采用標准模塊化格式，JSR 294專家組目前正在討論簡單模塊系統提議：在這 一提議中，Java類庫（來自Maven庫及Apache.org）的開發者能夠提供讓Jigsaw和OSGi系 統都能使用的元信息。結合對Java語言的微小變動（最值得關注的是增加的module關鍵字 ），這一信息可以在編譯時由高級編譯器產生。運行時系統（如Jigsaw或OSGi）可以使用 這些信息來校驗所安裝的模塊及其依賴。
總結
本文討論了模塊化的一般概念，以及在Java系統中是如何實現的。由於編譯時和運行 時路徑可能不同，有可能會產生不一致的類庫需求，從而導致依賴地獄。然 而，plugin API允許裝載多種代碼，但其必須遵循宿主的依賴處理規則，這又增加了發生不一致的可 能性。為了防止這種情況出現，像OSGi這樣的運行時模塊化系統可以在決定應用是否能被 正確啟動之前就校驗各項要求，而不是在運行時不知不覺發生錯誤。
最後，有人在正在進行中的JSR 294的郵件列表中提出，要為Java語言創建一個模塊系 統，其可以完全在Java語言規范中被定義，以便Java開發者可以產生帶有編碼依賴信息的 標定過版本的模塊，該模塊以後可以用於任何模塊系統。
