在過(guò)去幾年，Java模塊化一直是一個(gè)活躍的話題。從JSR 277（現(xiàn)已廢止）到JSR 291，模塊化看起來(lái)是Java進(jìn)化過(guò)程中的必經(jīng)一環(huán)。即便是基于JVM的未來(lái)語(yǔ)言，比如Scala，也考慮了模塊化的問(wèn)題。本文是關(guān)于模塊化Java系列文章中的第一篇，討論模塊化的含義，以及為什么要關(guān)注它。

51CTO編輯推薦：OSGi入門(mén)與實(shí)踐全攻略

什么是模塊化？

模塊化是個(gè)一般概念，這一概念也適用于軟件開(kāi)發(fā)，可以讓軟件按模塊單獨(dú)開(kāi)發(fā)，各模塊通常都用一個(gè)標(biāo)準(zhǔn)化的接口來(lái)進(jìn)行通信。實(shí)際上，除了規(guī)模大小有區(qū)別外，面向?qū)ο笳Z(yǔ)言中對(duì)象之間的關(guān)注點(diǎn)分離與模塊化的概念基本一致。通常，把系統(tǒng)劃分外多個(gè)模塊有助于將耦合減至最低，讓代碼維護(hù)更加簡(jiǎn)單。

Java語(yǔ)言并不是按照模塊化思想設(shè)計(jì)的（除了package，按照J(rèn)ava語(yǔ)言規(guī)范introduction一 節(jié)的介紹，package類(lèi)似于Modula-3模塊），但是在Java社區(qū)依然有很多實(shí)際存在的模塊。任何一個(gè)Java類(lèi)庫(kù)實(shí)際上都是一個(gè)模塊，無(wú)論其 是Log4J、Hibernate還是Tomcat。通常，開(kāi)源和非開(kāi)源的應(yīng)用都會(huì)依賴(lài)于一個(gè)或多個(gè)外部類(lèi)庫(kù)，而這種依賴(lài)關(guān)系又有可能傳遞到其他類(lèi)庫(kù)上。

類(lèi)庫(kù)也是模塊

類(lèi)庫(kù)毫無(wú)疑問(wèn)也是模塊。對(duì)于類(lèi)庫(kù)來(lái)講，可能沒(méi)有一個(gè)單一接口與之通信，但往往卻有‘public’ API（可能被用到）和‘private’ package（文檔中說(shuō)明了其用途）。此外，它們也有自己依賴(lài)的類(lèi)庫(kù)（比如JMX或JMS）。這將引起自動(dòng)依賴(lài)管理器引入許多并非必須的類(lèi)庫(kù)：以Log4J-1.2.15為例，引入了超過(guò)10個(gè)依賴(lài)類(lèi)庫(kù)（包括javax.mail和javax.jms），盡管這些類(lèi)庫(kù)中有不少對(duì)于使用Log4J的程序來(lái)說(shuō)根本不需要。

某些情況下，一個(gè)模塊的依賴(lài)可以是可選的；換句話說(shuō)，該模塊可能有一個(gè)功能子集缺少依賴(lài)。在上面的例子中，如果JMS沒(méi)有出現(xiàn)在運(yùn)行時(shí) classpath中，那么通過(guò)JMS記錄日志的功能將不可用，但是其他功能還是可以使用的。（Java通過(guò)使用延遲鏈接——deferred linking來(lái)達(dá)到這一目的：直到要訪問(wèn)一個(gè)類(lèi)時(shí)才需要其出現(xiàn)，缺少的依賴(lài)可以通過(guò)ClassNotFoundException來(lái)處理。其他一些平臺(tái)的弱鏈接——weak linking概念也是做類(lèi)似的運(yùn)行時(shí)檢查。）

通常，模塊都附帶一個(gè)版本號(hào)。許多開(kāi)源項(xiàng)目生成的發(fā)行版都是以類(lèi)似log4j-1.2.15.jar的方式命名的。這樣開(kāi)發(fā)者就可以在運(yùn)行時(shí)通過(guò)手動(dòng)方式來(lái)檢測(cè)特定開(kāi)源類(lèi)庫(kù)的版本?？墒?，程序編譯的時(shí)候可能使用了另一個(gè)不同版本的類(lèi)庫(kù)：假定編譯時(shí)用log4j-1.2.3.jar而運(yùn)行時(shí)用log4j-1.2.15.jar，程序在行為上依然能夠保持兼容。即使升級(jí)到下一個(gè)小版本，仍然是兼容的（這就是為什么log4j 1.3 的問(wèn)題會(huì)導(dǎo)致一個(gè)新分支2.0產(chǎn)生，以表示兼容性被打破）。所有這些都是基于慣例而非運(yùn)行時(shí)已知約束。

模塊化何時(shí)能派上用場(chǎng)？

作為一般概念，模塊化有助于將應(yīng)用分解為不同的部件，各個(gè)部件可以單獨(dú)測(cè)試（和開(kāi)發(fā)）。正如上面所提到的，大多數(shù)類(lèi)庫(kù)都是模塊。那么，對(duì)于那些生產(chǎn)類(lèi)庫(kù)提 供給別人使用的人來(lái)說(shuō)，模塊化是一個(gè)非常重要的概念。通常，依賴(lài)信息是在構(gòu)建工具（maven pom 或 ivy-module）里進(jìn)行編碼并被明確記錄在類(lèi)庫(kù)使用文檔中的。另外，高層類(lèi)庫(kù)開(kāi)發(fā)過(guò)程中需要修改較低層級(jí)類(lèi)庫(kù)bug，以提供更好支持的情況并不少 見(jiàn)，即便低層類(lèi)庫(kù)的最新版本已經(jīng)對(duì)bug進(jìn)行了修正。（可是有時(shí)候這種情況可能會(huì)導(dǎo)致出現(xiàn)一些微妙的問(wèn)題。）

如果一個(gè)類(lèi)庫(kù)是提供給他人使用的，那么它就已經(jīng)是一個(gè)模塊了。但是世上鮮有“Hello World”這樣的類(lèi)庫(kù)，也鮮有“Hello World”這樣的模塊。只有當(dāng)應(yīng)用足夠大時(shí)（或者是用一個(gè)模塊化構(gòu)建系統(tǒng)進(jìn)行構(gòu)建時(shí)），把應(yīng)用劃分為不同部件的概念就派上用場(chǎng)了。

模塊化的好處之一是便于測(cè)試。一個(gè)小模塊（具有定義良好的API）通常比應(yīng)用整體更好測(cè)試。在GUI應(yīng)用中尤其如此，GUI自身可能不好測(cè)試，但是其調(diào)用的代碼卻是可測(cè)試的。

模塊化的另一個(gè)好處是便于進(jìn)化。盡管系統(tǒng)整體有一個(gè)版本號(hào)，但實(shí)際上，其下有多個(gè)模塊及相應(yīng)版本（不論開(kāi)源與否，總有一些類(lèi)庫(kù)——甚至是Java版本—— 是系統(tǒng)所依賴(lài)的）。這樣，每個(gè)模塊都可以自己的方式自由地進(jìn)化。某些模塊進(jìn)化得快些，另一些則會(huì)長(zhǎng)期保持穩(wěn)定（例如，Eclipse 3.5 的org.eclipse.core.boot從2008年2月以來(lái)一直沒(méi)有改變過(guò)）。

模塊化也可給項(xiàng)目管理帶來(lái)方便。如果一個(gè)模塊公布的API可供其他模塊預(yù)先使用，那么各個(gè)模塊就可以由不同的團(tuán)隊(duì)分別開(kāi)發(fā)。這在大型項(xiàng)目中必定會(huì)發(fā)生，各個(gè)項(xiàng)目子團(tuán)隊(duì)可以負(fù)責(zé)不同模塊的交付。

最后，將一個(gè)應(yīng)用程序模塊化，可以幫助識(shí)別正在使用依賴(lài)類(lèi)庫(kù)的哪個(gè)版本，以便協(xié)調(diào)大型項(xiàng)目中的類(lèi)庫(kù)依賴(lài)。

運(yùn)行時(shí)與編譯時(shí)

無(wú)論在編譯時(shí)還是運(yùn)行時(shí)，Java的classpath都是扁平的。換句話說(shuō)，應(yīng)用程序可以看到classpath上的所有類(lèi)，而不管其順序如何（如果沒(méi) 有重復(fù)，是這樣；否則，總是找最前面的）。這就使Java動(dòng)態(tài)鏈接成為可能：一個(gè)處于classpath前面的已裝載類(lèi)，不需要解析其所引用的可能處于 classpath后面的那些類(lèi)，直到確實(shí)需要他們?yōu)橹埂?/p>

如果所使用的接口實(shí)現(xiàn)到運(yùn)行時(shí)才能清楚，通常使用這種方法。例如，一個(gè)SQL工具可以依賴(lài)普通JDBC包來(lái)編譯，而運(yùn)行時(shí)（可以有附加配置信息）可以實(shí)例化適當(dāng)?shù)腏DBC驅(qū)動(dòng)。這通常是在運(yùn)行時(shí)將類(lèi)名（實(shí)現(xiàn)了預(yù)定義的工廠接口或抽象類(lèi)）提供給Class.forName查找來(lái)實(shí)現(xiàn)。如果指定的類(lèi)不存在（或者由于其他原因不能加載），則會(huì)產(chǎn)生一個(gè)錯(cuò)誤。

因此，模塊的編譯時(shí)classpath可能會(huì)與運(yùn)行時(shí)classpath有些微妙的差別。此外，每個(gè)模塊通常都是獨(dú)立編譯的（模塊A可能是用模塊C 1.1 來(lái)編譯的，而模塊B則可能是用模塊C 1.2 來(lái)編譯的），而另一方面，在運(yùn)行時(shí)則是使用單一的路徑（在本例中，即可能是模塊C的1.1版本，也可能是1.2版本）。這就會(huì)導(dǎo)致依賴(lài)地獄（Dependency Hell），特別當(dāng)它是這些依賴(lài)傳遞的末尾時(shí)更是這樣。不過(guò)，像Maven和Ivy這樣的構(gòu)建系統(tǒng)可以讓模塊化特性對(duì)開(kāi)發(fā)者是可見(jiàn)的，甚至對(duì)最終用戶(hù)也是可見(jiàn)的。

Java有一個(gè)非常好的底層特性，叫做ClassLoader， 它可以讓運(yùn)行時(shí)路徑分得更開(kāi)。通常情況下，所有類(lèi)都是由系統(tǒng)ClassLoader裝載的；可是有些系統(tǒng)使用不同的ClassLoader將其運(yùn)行時(shí)空間 進(jìn)行了劃分。Tomacat(或者其他Servlet引擎)就是一個(gè)很好的例子，每個(gè)Web應(yīng)用都有一個(gè)ClassLoader。這樣Web應(yīng)用就不必去 管（無(wú)論有意與否）在同一JVM中其他Web應(yīng)用所定義的類(lèi)。

這種方式下，每個(gè)Web應(yīng)用都用自己的ClassLoader裝載類(lèi)，這樣一個(gè)（本地）Web應(yīng)用實(shí)現(xiàn)裝載的類(lèi)不會(huì)與其他Web應(yīng)用實(shí)現(xiàn)相沖突。但這就要 求對(duì)任何ClassLoader鏈，類(lèi)空間都是一致的；這意味著在同一時(shí)刻，你的VM可以同時(shí)從兩個(gè)不同的Classloader中各自裝載一個(gè)Util.class， 只要這兩個(gè)ClassLoader互相不可見(jiàn)。（這也是為什么Servlet引擎具有無(wú)需重啟即可重新部署的能力；扔掉了一個(gè)ClassLoader，你 也就扔掉了其引用類(lèi)，讓老版本符合垃圾回收的條件——然后讓Servlet引擎創(chuàng)建一個(gè)新的ClassLoader并在運(yùn)行時(shí)中重新部署應(yīng)用類(lèi)的新版本。）

再談模塊

構(gòu)建一個(gè)模塊化系統(tǒng)實(shí)際上是把系統(tǒng)劃分成（有可能）可重用模塊的過(guò)程，并使模塊間耦合最小化。同時(shí)，其也是一個(gè)減少模塊需求耦合的過(guò)程：例如，Eclipse IDE許多plugin對(duì)GUI和非GUI組件（如jdt.ui和jdt.core）的依賴(lài)是分開(kāi)的，這樣就可以在IDE環(huán)境之外使用這些非GUI模塊（headless builds、分析及錯(cuò)誤檢查等等）。

除了作為整體的rt.jar之外，任何其他系統(tǒng)都可以被分解為不同的模塊。問(wèn)題是這么做是否值得？畢竟，從頭構(gòu)建一個(gè)模塊化系統(tǒng)比起把一個(gè)單模塊系統(tǒng)分割成多個(gè)模塊要容易得多。

之所以這樣，原因之一是跨越模塊邊界的類(lèi)泄漏。例如，java.beans包邏輯上不應(yīng)該依賴(lài)于任何GUI代碼；可是Beans.instantiate()所使用的java.beans.AppletInitializer引用了Applet，這必然導(dǎo)致對(duì)整個(gè)AWT的依賴(lài)。因此從技術(shù)上講java.beans有依賴(lài)于AWT的選項(xiàng)，盡管常識(shí)告訴我們不應(yīng)該有。如果核心java類(lèi)庫(kù)從一開(kāi)始就采用了模塊化方法來(lái)構(gòu)建，那么這種錯(cuò)誤早在API公布之前就發(fā)現(xiàn)了。

有些情況下，一個(gè)模塊看上去不能再被劃分成子模塊了?？墒?，有時(shí)候相關(guān)功能保持在同一個(gè)模塊中是為了便于組織，當(dāng)需要的時(shí)候還可以再進(jìn)一步分解。例如，對(duì)重構(gòu)的支持起初是Eclipse JDT的一部分，現(xiàn)在被抽出為一個(gè)模塊，以便其他語(yǔ)言（如CDT）利用其重構(gòu)能力。

Plugins

許多系統(tǒng)都是通過(guò)plugin概念進(jìn)行擴(kuò)展的。在這種情況下，宿主系統(tǒng)定義了一套plugin必須遵循的API及plugin注入方式。許多應(yīng)用（如Web瀏覽器、IDE及構(gòu)建工具）通常都是通過(guò)提供帶有適當(dāng)API的插件來(lái)對(duì)應(yīng)用進(jìn)行定制的。

有時(shí)候這些plugin受到限制或只有一些普通操作（音頻或視頻解碼），但是組織起來(lái)效果也非常不錯(cuò)（例如，IDE的眾多plugin）。有時(shí)候，這些 plugin可以提供自己的plugin，以便進(jìn)一步定制行為，使得系統(tǒng)具有更高可定制性。（可是，增加這些中間層級(jí)會(huì)使系統(tǒng)難以理解。）

這種plugin API成為各個(gè)plugin必須遵守的契約的一部分。這些plugin自己也是模塊，也面臨依賴(lài)鏈和版本問(wèn)題。由于（特定）plugin API演化的復(fù)雜性，因此plugin自己也面臨這一問(wèn)題（必須維持向后兼容性）。

Netscape plugin API成功的原因之一是其簡(jiǎn)單性：只需實(shí)現(xiàn)少量的函數(shù)。只要宿主瀏覽器用適當(dāng)?shù)腗IME類(lèi)型將輸入重定向，plugin就可以處理其他事情?？墒牵鼜?fù)雜的應(yīng)用（如IDE）通常需要更緊密集成各個(gè)模塊，因此需要一個(gè)更復(fù)雜的API來(lái)推動(dòng)。

Java模塊化的當(dāng)前狀態(tài)

目前，Java領(lǐng)域存在許多模塊化系統(tǒng)和plugin體系。IDE是名氣最大的，IntelliJ、NetBeans和Eclipse都提供了其自己的 plugin系統(tǒng)作為其定制途徑。而且，構(gòu)建系統(tǒng)（Ant、Maven）甚至終端用戶(hù)應(yīng)用（Lotus Notes、Mac AppleScript應(yīng)用）都有能夠擴(kuò)展應(yīng)用或系統(tǒng)核心功能的概念。

OSGi是Java領(lǐng)域里無(wú)可辯駁的最成熟的模塊系統(tǒng)，它與Java幾乎是如影相隨，最早出現(xiàn)于JSR 8，但是最新規(guī)范是JSR 291。 OSGi在JAR的MANIFEST.MF文件中定義了額外的元數(shù)據(jù)，用來(lái)指明每個(gè)包所要求的依賴(lài)。這就讓模塊能夠（在運(yùn)行時(shí)）檢查其依賴(lài)是否滿(mǎn)足要求， 另外，可以讓每個(gè)模塊有自己的私有 classpath（因?yàn)槊總€(gè)模塊都有一個(gè)ClassLoader）。這可以讓dependency hell盡早被發(fā)現(xiàn)，但是不能完全避免。和JDBC一樣，OSGi也是規(guī)范（目前是4.2版），有多個(gè)開(kāi)源（及商業(yè)）實(shí)現(xiàn)。因?yàn)槟K不需要依賴(lài)任何OSGi的特定代碼，許多開(kāi)源類(lèi)庫(kù)現(xiàn)在都將其元信息嵌入到manifest中，以便OSGi運(yùn)行時(shí)使用。有些程序包沒(méi)有這么做，也可以用bnd這樣的工具，它可以處理一個(gè)已有的JAR文件并為其產(chǎn)生合適的默認(rèn)元信息。自2004年Eclipse 3.0 從專(zhuān)有plugin系統(tǒng)切換到OSGi之后，許多其他專(zhuān)有內(nèi)核系統(tǒng)（JBoss、WebSphere、Weblogic）也都隨之將其運(yùn)行時(shí)轉(zhuǎn)向基于OSGi內(nèi)核。

最近創(chuàng)建的Jigsaw項(xiàng)目是為了模塊化JDK自身。盡管其是JDK內(nèi)部的一部分，并且很可能在其他SE 7 實(shí)現(xiàn)中不被支持，但是在該JDK之外使用Jigsaw并無(wú)限制。盡管仍在開(kāi)發(fā)當(dāng)中，Jigsaw還很可能成為前面提到的JSR 294的參考實(shí)現(xiàn)。最低要求SE 7（加上目前還沒(méi)有Java 7的事實(shí)）說(shuō)明了Jigsaw仍在開(kāi)發(fā)中，而且運(yùn)行在Java 6或更低版本上的系統(tǒng)基本上是用不上了。

為了鼓勵(lì)采用標(biāo)準(zhǔn)模塊化格式，JSR 294專(zhuān)家組目前正在討論簡(jiǎn)單模塊系統(tǒng)提議：在這一提議中，Java類(lèi)庫(kù)（來(lái)自Maven庫(kù)及Apache.org）的開(kāi)發(fā)者能夠提供讓Jigsaw和OSGi系統(tǒng)都能使用的元信息。結(jié)合對(duì)Java語(yǔ)言的微小變動(dòng)（最值得關(guān)注的是增加的module關(guān)鍵字），這一信息可以在編譯時(shí)由高級(jí)編譯器產(chǎn)生。運(yùn)行時(shí)系統(tǒng)（如Jigsaw或OSGi）可以使用這些信息來(lái)校驗(yàn)所安裝的模塊及其依賴(lài)。

總結(jié)

本文討論了模塊化的一般概念，以及在Java系統(tǒng)中是如何實(shí)現(xiàn)的。由于編譯時(shí)和運(yùn)行時(shí)路徑可能不同，有可能會(huì)產(chǎn)生不一致的類(lèi)庫(kù)需求，從而導(dǎo)致依賴(lài)地獄。然 而，plugin API允許裝載多種代碼，但其必須遵循宿主的依賴(lài)處理規(guī)則，這又增加了發(fā)生不一致的可能性。為了防止這種情況出現(xiàn)，像OSGi這樣的運(yùn)行時(shí)模塊化系統(tǒng)可以 在決定應(yīng)用是否能被正確啟動(dòng)之前就校驗(yàn)各項(xiàng)要求，而不是在運(yùn)行時(shí)不知不覺(jué)發(fā)生錯(cuò)誤。

最后，有人在正在進(jìn)行中的JSR 294的郵件列表中提出，要為Java語(yǔ)言創(chuàng)建一個(gè)模塊系統(tǒng)，其可以完全在Java語(yǔ)言規(guī)范中被定義，以便Java開(kāi)發(fā)者可以產(chǎn)生帶有編碼依賴(lài)信息的標(biāo)定過(guò)版本的模塊，該模塊以后可以用于任何模塊系統(tǒng)。

本文來(lái)源：InfoQ，宋瑋 譯。原文標(biāo)題《模塊化Java簡(jiǎn)介》：http://www.infoq.com/cn/articles/modular-java-what-is-it