模塊化Java簡介

模塊化Java簡介

在過去幾年，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開發者能夠產生帶有編碼依賴信息的標定過版本的模塊，該模塊之後能夠用於任何模塊系統。

查看英文原文：Modular Java: What Is It?。

轉自：http://www.infoq.com/cn/articles/modular-java-what-is-it/