建站
咨詢
售后
建站咨詢
新聞中心
在過去幾年，Java模塊化一直是一個(gè)活躍的話題。從JSR 277（現(xiàn)已廢止）到JSR 291，模塊化看起來是Java進(jìn)化過程中的必經(jīng)一環(huán)。即便是基于JVM的未來語言，比如Scala，也考慮了模塊化的問題。本文是關(guān)于模塊化Java系列文章中的第一篇，討論模塊化的含義，以及為什么要關(guān)注它。
創(chuàng)新互聯(lián)建站堅(jiān)信：善待客戶，將會(huì)成為終身客戶。我們能堅(jiān)持多年，是因?yàn)槲覀円恢笨芍档眯刨嚒Ｎ覀儚牟缓鲇瞥踉L客戶，我們用心做好本職工作，不忘初心，方得始終。十余年網(wǎng)站建設(shè)經(jīng)驗(yàn)創(chuàng)新互聯(lián)建站是成都老牌網(wǎng)站營銷服務(wù)商,為您提供做網(wǎng)站、網(wǎng)站設(shè)計(jì)、網(wǎng)站設(shè)計(jì)、HTML5建站、網(wǎng)站制作、成都品牌網(wǎng)站建設(shè)、重慶小程序開發(fā)服務(wù),給眾多知名企業(yè)提供過好品質(zhì)的建站服務(wù)。
編輯推薦：OSGi入門與實(shí)踐全攻略
什么是模塊化？
模塊化是個(gè)一般概念，這一概念也適用于軟件開發(fā)，可以讓軟件按模塊單獨(dú)開發(fā)，各模塊通常都用一個(gè)標(biāo)準(zhǔn)化的接口來進(jìn)行通信。實(shí)際上，除了規(guī)模大小有區(qū)別外，面向?qū)ο笳Z言中對(duì)象之間的關(guān)注點(diǎn)分離與模塊化的概念基本一致。通常，把系統(tǒng)劃分外多個(gè)模塊有助于將耦合減至最低，讓代碼維護(hù)更加簡(jiǎn)單。
Java語言并不是按照模塊化思想設(shè)計(jì)的（除了package，按照J(rèn)ava語言規(guī)范introduction一 節(jié)的介紹，package類似于Modula-3模塊），但是在Java社區(qū)依然有很多實(shí)際存在的模塊。任何一個(gè)Java類庫實(shí)際上都是一個(gè)模塊，無論其 是Log4J、Hibernate還是Tomcat。通常，開源和非開源的應(yīng)用都會(huì)依賴于一個(gè)或多個(gè)外部類庫，而這種依賴關(guān)系又有可能傳遞到其他類庫上。
類庫也是模塊
類庫毫無疑問也是模塊。對(duì)于類庫來講，可能沒有一個(gè)單一接口與之通信，但往往卻有‘public’ API（可能被用到）和‘private’ package（文檔中說明了其用途）。此外，它們也有自己依賴的類庫（比如JMX或JMS）。這將引起自動(dòng)依賴管理器引入許多并非必須的類庫：以Log4J-1.2.15為例，引入了超過10個(gè)依賴類庫（包括javax.mail和javax.jms），盡管這些類庫中有不少對(duì)于使用Log4J的程序來說根本不需要。
某些情況下，一個(gè)模塊的依賴可以是可選的；換句話說，該模塊可能有一個(gè)功能子集缺少依賴。在上面的例子中，如果JMS沒有出現(xiàn)在運(yùn)行時(shí) classpath中，那么通過JMS記錄日志的功能將不可用，但是其他功能還是可以使用的。（Java通過使用延遲鏈接——deferred linking來達(dá)到這一目的：直到要訪問一個(gè)類時(shí)才需要其出現(xiàn)，缺少的依賴可以通過ClassNotFoundException來處理。其他一些平臺(tái)的弱鏈接——weak linking概念也是做類似的運(yùn)行時(shí)檢查。）
通常，模塊都附帶一個(gè)版本號(hào)。許多開源項(xiàng)目生成的發(fā)行版都是以類似log4j-1.2.15.jar的方式命名的。這樣開發(fā)者就可以在運(yùn)行時(shí)通過手動(dòng)方式來檢測(cè)特定開源類庫的版本?？墒?，程序編譯的時(shí)候可能使用了另一個(gè)不同版本的類庫：假定編譯時(shí)用log4j-1.2.3.jar而運(yùn)行時(shí)用log4j-1.2.15.jar，程序在行為上依然能夠保持兼容。即使升級(jí)到下一個(gè)小版本，仍然是兼容的（這就是為什么log4j 1.3 的問題會(huì)導(dǎo)致一個(gè)新分支2.0產(chǎn)生，以表示兼容性被打破）。所有這些都是基于慣例而非運(yùn)行時(shí)已知約束。
模塊化何時(shí)能派上用場(chǎng)？
作為一般概念，模塊化有助于將應(yīng)用分解為不同的部件，各個(gè)部件可以單獨(dú)測(cè)試（和開發(fā)）。正如上面所提到的，大多數(shù)類庫都是模塊。那么，對(duì)于那些生產(chǎn)類庫提 供給別人使用的人來說，模塊化是一個(gè)非常重要的概念。通常，依賴信息是在構(gòu)建工具（maven pom 或 ivy-module）里進(jìn)行編碼并被明確記錄在類庫使用文檔中的。另外，高層類庫開發(fā)過程中需要修改較低層級(jí)類庫bug，以提供更好支持的情況并不少 見，即便低層類庫的最新版本已經(jīng)對(duì)bug進(jìn)行了修正。（可是有時(shí)候這種情況可能會(huì)導(dǎo)致出現(xiàn)一些微妙的問題。）
如果一個(gè)類庫是提供給他人使用的，那么它就已經(jīng)是一個(gè)模塊了。但是世上鮮有“Hello World”這樣的類庫，也鮮有“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)版本（不論開源與否，總有一些類庫——甚至是Java版本—— 是系統(tǒng)所依賴的）。這樣，每個(gè)模塊都可以自己的方式自由地進(jìn)化。某些模塊進(jìn)化得快些，另一些則會(huì)長(zhǎng)期保持穩(wěn)定（例如，Eclipse 3.5 的org.eclipse.core.boot從2008年2月以來一直沒有改變過）。
模塊化也可給項(xiàng)目管理帶來方便。如果一個(gè)模塊公布的API可供其他模塊預(yù)先使用，那么各個(gè)模塊就可以由不同的團(tuán)隊(duì)分別開發(fā)。這在大型項(xiàng)目中必定會(huì)發(fā)生，各個(gè)項(xiàng)目子團(tuán)隊(duì)可以負(fù)責(zé)不同模塊的交付。
最后，將一個(gè)應(yīng)用程序模塊化，可以幫助識(shí)別正在使用依賴類庫的哪個(gè)版本，以便協(xié)調(diào)大型項(xiàng)目中的類庫依賴。
運(yùn)行時(shí)與編譯時(shí)
無論在編譯時(shí)還是運(yùn)行時(shí)，Java的classpath都是扁平的。換句話說，應(yīng)用程序可以看到classpath上的所有類，而不管其順序如何（如果沒 有重復(fù)，是這樣；否則，總是找最前面的）。這就使Java動(dòng)態(tài)鏈接成為可能：一個(gè)處于classpath前面的已裝載類，不需要解析其所引用的可能處于 classpath后面的那些類，直到確實(shí)需要他們?yōu)橹埂?/p>
如果所使用的接口實(shí)現(xiàn)到運(yùn)行時(shí)才能清楚，通常使用這種方法。例如，一個(gè)SQL工具可以依賴普通JDBC包來編譯，而運(yùn)行時(shí)（可以有附加配置信息）可以實(shí)例化適當(dāng)?shù)腏DBC驅(qū)動(dòng)。這通常是在運(yùn)行時(shí)將類名（實(shí)現(xiàn)了預(yù)定義的工廠接口或抽象類）提供給Class.forName查找來實(shí)現(xiàn)。如果指定的類不存在（或者由于其他原因不能加載），則會(huì)產(chǎn)生一個(gè)錯(cuò)誤。
因此，模塊的編譯時(shí)classpath可能會(huì)與運(yùn)行時(shí)classpath有些微妙的差別。此外，每個(gè)模塊通常都是獨(dú)立編譯的（模塊A可能是用模塊C 1.1 來編譯的，而模塊B則可能是用模塊C 1.2 來編譯的），而另一方面，在運(yùn)行時(shí)則是使用單一的路徑（在本例中，即可能是模塊C的1.1版本，也可能是1.2版本）。這就會(huì)導(dǎo)致依賴地獄（Dependency Hell），特別當(dāng)它是這些依賴傳遞的末尾時(shí)更是這樣。不過，像Maven和Ivy這樣的構(gòu)建系統(tǒng)可以讓模塊化特性對(duì)開發(fā)者是可見的，甚至對(duì)最終用戶也是可見的。
Java有一個(gè)非常好的底層特性，叫做ClassLoader， 它可以讓運(yùn)行時(shí)路徑分得更開。通常情況下，所有類都是由系統(tǒng)ClassLoader裝載的；可是有些系統(tǒng)使用不同的ClassLoader將其運(yùn)行時(shí)空間 進(jìn)行了劃分。Tomacat(或者其他Servlet引擎)就是一個(gè)很好的例子，每個(gè)Web應(yīng)用都有一個(gè)ClassLoader。這樣Web應(yīng)用就不必去 管（無論有意與否）在同一JVM中其他Web應(yīng)用所定義的類。
這種方式下，每個(gè)Web應(yīng)用都用自己的ClassLoader裝載類，這樣一個(gè)（本地）Web應(yīng)用實(shí)現(xiàn)裝載的類不會(huì)與其他Web應(yīng)用實(shí)現(xiàn)相沖突。但這就要 求對(duì)任何ClassLoader鏈，類空間都是一致的；這意味著在同一時(shí)刻，你的VM可以同時(shí)從兩個(gè)不同的Classloader中各自裝載一個(gè)Util.class， 只要這兩個(gè)ClassLoader互相不可見。（這也是為什么Servlet引擎具有無需重啟即可重新部署的能力；扔掉了一個(gè)ClassLoader，你 也就扔掉了其引用類，讓老版本符合垃圾回收的條件——然后讓Servlet引擎創(chuàng)建一個(gè)新的ClassLoader并在運(yùn)行時(shí)中重新部署應(yīng)用類的新版本。）
再談模塊
構(gòu)建一個(gè)模塊化系統(tǒng)實(shí)際上是把系統(tǒng)劃分成（有可能）可重用模塊的過程，并使模塊間耦合最小化。同時(shí)，其也是一個(gè)減少模塊需求耦合的過程：例如，Eclipse IDE許多plugin對(duì)GUI和非GUI組件（如jdt.ui和jdt.core）的依賴是分開的，這樣就可以在IDE環(huán)境之外使用這些非GUI模塊（headless builds、分析及錯(cuò)誤檢查等等）。
除了作為整體的rt.jar之外，任何其他系統(tǒng)都可以被分解為不同的模塊。問題是這么做是否值得？畢竟，從頭構(gòu)建一個(gè)模塊化系統(tǒng)比起把一個(gè)單模塊系統(tǒng)分割成多個(gè)模塊要容易得多。
之所以這樣，原因之一是跨越模塊邊界的類泄漏。例如，java.beans包邏輯上不應(yīng)該依賴于任何GUI代碼；可是Beans.instantiate()所使用的java.beans.AppletInitializer引用了Applet，這必然導(dǎo)致對(duì)整個(gè)AWT的依賴。因此從技術(shù)上講java.beans有依賴于AWT的選項(xiàng)，盡管常識(shí)告訴我們不應(yīng)該有。如果核心java類庫從一開始就采用了模塊化方法來構(gòu)建，那么這種錯(cuò)誤早在API公布之前就發(fā)現(xiàn)了。
有些情況下，一個(gè)模塊看上去不能再被劃分成子模塊了?？墒牵袝r(shí)候相關(guān)功能保持在同一個(gè)模塊中是為了便于組織，當(dāng)需要的時(shí)候還可以再進(jìn)一步分解。例如，對(duì)重構(gòu)的支持起初是Eclipse JDT的一部分，現(xiàn)在被抽出為一個(gè)模塊，以便其他語言（如CDT）利用其重構(gòu)能力。
Plugins
許多系統(tǒng)都是通過plugin概念進(jìn)行擴(kuò)展的。在這種情況下，宿主系統(tǒng)定義了一套plugin必須遵循的API及plugin注入方式。許多應(yīng)用（如Web瀏覽器、IDE及構(gòu)建工具）通常都是通過提供帶有適當(dāng)API的插件來對(duì)應(yīng)用進(jìn)行定制的。
有時(shí)候這些plugin受到限制或只有一些普通操作（音頻或視頻解碼），但是組織起來效果也非常不錯(cuò)（例如，IDE的眾多plugin）。有時(shí)候，這些 plugin可以提供自己的plugin，以便進(jìn)一步定制行為，使得系統(tǒng)具有更高可定制性。（可是，增加這些中間層級(jí)會(huì)使系統(tǒng)難以理解。）
這種plugin API成為各個(gè)plugin必須遵守的契約的一部分。這些plugin自己也是模塊，也面臨依賴鏈和版本問題。由于（特定）plugin API演化的復(fù)雜性，因此plugin自己也面臨這一問題（必須維持向后兼容性）。
Netscape plugin API成功的原因之一是其簡(jiǎn)單性：只需實(shí)現(xiàn)少量的函數(shù)。只要宿主瀏覽器用適當(dāng)?shù)腗IME類型將輸入重定向，plugin就可以處理其他事情?？墒?，更復(fù)雜的應(yīng)用（如IDE）通常需要更緊密集成各個(gè)模塊，因此需要一個(gè)更復(fù)雜的API來推動(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）甚至終端用戶應(yīng)用（Lotus Notes、Mac AppleScript應(yīng)用）都有能夠擴(kuò)展應(yīng)用或系統(tǒng)核心功能的概念。
OSGi是Java領(lǐng)域里無可辯駁的最成熟的模塊系統(tǒng)，它與Java幾乎是如影相隨，最早出現(xiàn)于JSR 8，但是最新規(guī)范是JSR 291。 OSGi在JAR的MANIFEST.MF文件中定義了額外的元數(shù)據(jù)，用來指明每個(gè)包所要求的依賴。這就讓模塊能夠（在運(yùn)行時(shí)）檢查其依賴是否滿足要求， 另外，可以讓每個(gè)模塊有自己的私有 classpath（因?yàn)槊總€(gè)模塊都有一個(gè)ClassLoader）。這可以讓dependency hell盡早被發(fā)現(xiàn)，但是不能完全避免。和JDBC一樣，OSGi也是規(guī)范（目前是4.2版），有多個(gè)開源（及商業(yè)）實(shí)現(xiàn)。因?yàn)槟K不需要依賴任何OSGi的特定代碼，許多開源類庫現(xiàn)在都將其元信息嵌入到manifest中，以便OSGi運(yùn)行時(shí)使用。有些程序包沒有這么做，也可以用bnd這樣的工具，它可以處理一個(gè)已有的JAR文件并為其產(chǎn)生合適的默認(rèn)元信息。自2004年Eclipse 3.0 從專有plugin系統(tǒng)切換到OSGi之后，許多其他專有內(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并無限制。盡管仍在開發(fā)當(dāng)中，Jigsaw還很可能成為前面提到的JSR 294的參考實(shí)現(xiàn)。最低要求SE 7（加上目前還沒有Java 7的事實(shí)）說明了Jigsaw仍在開發(fā)中，而且運(yùn)行在Java 6或更低版本上的系統(tǒng)基本上是用不上了。
為了鼓勵(lì)采用標(biāo)準(zhǔn)模塊化格式，JSR 294專家組目前正在討論簡(jiǎn)單模塊系統(tǒng)提議：在這一提議中，Java類庫（來自Maven庫及Apache.org）的開發(fā)者能夠提供讓Jigsaw和OSGi系統(tǒng)都能使用的元信息。結(jié)合對(duì)Java語言的微小變動(dòng)（最值得關(guān)注的是增加的module關(guān)鍵字），這一信息可以在編譯時(shí)由高級(jí)編譯器產(chǎn)生。運(yùn)行時(shí)系統(tǒng)（如Jigsaw或OSGi）可以使用這些信息來校驗(yàn)所安裝的模塊及其依賴。
總結(jié)
本文討論了模塊化的一般概念，以及在Java系統(tǒng)中是如何實(shí)現(xiàn)的。由于編譯時(shí)和運(yùn)行時(shí)路徑可能不同，有可能會(huì)產(chǎn)生不一致的類庫需求，從而導(dǎo)致依賴地獄。然 而，plugin API允許裝載多種代碼，但其必須遵循宿主的依賴處理規(guī)則，這又增加了發(fā)生不一致的可能性。為了防止這種情況出現(xiàn)，像OSGi這樣的運(yùn)行時(shí)模塊化系統(tǒng)可以 在決定應(yīng)用是否能被正確啟動(dòng)之前就校驗(yàn)各項(xiàng)要求，而不是在運(yùn)行時(shí)不知不覺發(fā)生錯(cuò)誤。
最后，有人在正在進(jìn)行中的JSR 294的郵件列表中提出，要為Java語言創(chuàng)建一個(gè)模塊系統(tǒng)，其可以完全在Java語言規(guī)范中被定義，以便Java開發(fā)者可以產(chǎn)生帶有編碼依賴信息的標(biāo)定過版本的模塊，該模塊以后可以用于任何模塊系統(tǒng)。
本文來源：InfoQ，宋瑋 譯。原文標(biāo)題《模塊化Java簡(jiǎn)介》：http://www.infoq.com/cn/articles/modular-java-what-is-it
網(wǎng)站名稱：Java模塊化概念解惑與現(xiàn)狀總結(jié)
當(dāng)前URL：http://fisionsoft.com.cn/article/dhghjeo.html
