Java 7中有哪些模塊系統(tǒng)，很多新手對(duì)此不是很清楚，為了幫助大家解決這個(gè)難題，下面小編將為大家詳細(xì)講解，有這方面需求的人可以來(lái)學(xué)習(xí)下，希望你能有所收獲。

西峽網(wǎng)站制作公司哪家好，找成都創(chuàng)新互聯(lián)！從網(wǎng)頁(yè)設(shè)計(jì)、網(wǎng)站建設(shè)、微信開(kāi)發(fā)、APP開(kāi)發(fā)、成都響應(yīng)式網(wǎng)站建設(shè)公司等網(wǎng)站項(xiàng)目制作，到程序開(kāi)發(fā)，運(yùn)營(yíng)維護(hù)。成都創(chuàng)新互聯(lián)2013年開(kāi)創(chuàng)至今到現(xiàn)在10年的時(shí)間，我們擁有了豐富的建站經(jīng)驗(yàn)和運(yùn)維經(jīng)驗(yàn)，來(lái)保證我們的工作的順利進(jìn)行。專注于網(wǎng)站建設(shè)就選成都創(chuàng)新互聯(lián)。

模塊化

模塊化是解決復(fù)雜性問(wèn)題很重要的工具。把應(yīng)用分成不同的部分(模塊、庫(kù)、包、子項(xiàng)目和組件)，再分別進(jìn)行計(jì)算，是行之有效的方式。模塊化的最終目的是能定義出一套API用于模塊間的溝通。

如果模塊間所有的通訊都只通過(guò)這種API來(lái)實(shí)現(xiàn)，那么模塊是松耦合的，于是：

改變某個(gè)模塊的實(shí)現(xiàn)會(huì)很容易

開(kāi)發(fā)和測(cè)試各個(gè)模塊能很容易獨(dú)立開(kāi)來(lái)

面向?qū)ο竽Ｊ揭彩穷愃频牡览怼Ｔ贠OP中，理想的狀況是擁有大量小的、可重用的、簡(jiǎn)單并分離良好的對(duì)象。在模塊系統(tǒng)中，就可以***地實(shí)現(xiàn)小的、可重用的、簡(jiǎn)單并分離良好的模塊。它們的想法和最初的動(dòng)機(jī)是完全一樣的，只是規(guī)模有所不同。

邏輯分離

傳統(tǒng)上，Java中有兩種辦法來(lái)實(shí)現(xiàn)模塊化。邏輯分離是最自然的方式。它包括將應(yīng)用程序分割成邏輯模塊(子項(xiàng)目)，***再部署成一個(gè)完整的應(yīng)用。通過(guò)定義正確的包來(lái)實(shí)現(xiàn)邏輯分離也是可能的，但更通用的辦法是把應(yīng)用分割成一些存檔文件(也就是JAR包)。邏輯分離里能促進(jìn)模塊的重用，有助實(shí)現(xiàn)模塊間的松耦合。你甚至有可能定義一個(gè)API，然后宣布所有模塊間的通訊都要通過(guò)這個(gè)給定的API來(lái)實(shí)現(xiàn)。這樣的想法有個(gè)大問(wèn)題，那就是你很難強(qiáng)破大家都采用這種限制性用法，而且沒(méi)有任何一種機(jī)制能夠確保這個(gè)API的用法。你也沒(méi)法把那些應(yīng)用通過(guò)給定模塊來(lái)使用的類和作為公共API一部分的類區(qū)分開(kāi)來(lái)。如果一個(gè)類是“ 公共的”，那它就可以被任何其他類使用，無(wú)論調(diào)用它的那個(gè)類屬于哪個(gè)模塊。另一方面，受保護(hù)的或者包級(jí)可見(jiàn)性的類在其模塊內(nèi)部的調(diào)用也有限制。通常來(lái)說(shuō)，涵蓋了一些包以及包中類的模塊需要能夠互相調(diào)用。因此即使某個(gè)應(yīng)用是由一些邏輯模塊組成，但如果這些模塊是耦合的，那么分離也根本沒(méi)有用處。

物理分離

另外一個(gè)傳統(tǒng)的辦法就是物理上的分離。你可以通過(guò)將應(yīng)用分割成不同的組件，然后把每個(gè)組件部署到不同的JVM上而實(shí)現(xiàn)分離。這些組件間通過(guò)遠(yuǎn)程訪問(wèn)機(jī)制進(jìn)行通訊，比如RMI、CORBA或者WebServices。物理分離實(shí)現(xiàn)了分離，也實(shí)現(xiàn)了松耦合，但負(fù)面影響是開(kāi)支很大。為實(shí)現(xiàn)分離而專門(mén)采用遠(yuǎn)程訪問(wèn)機(jī)制，有點(diǎn)殺雞用牛刀的味道。這會(huì)增加開(kāi)發(fā)和部署不必要的復(fù)雜性，性能上所受到的影響也不能忽視的。

模塊系統(tǒng)

模塊系統(tǒng)的作用位于邏輯分離和物理分離之間。它強(qiáng)調(diào)模塊分離，但各個(gè)模塊仍然部署到同一個(gè)JVM中，而且模塊間的通訊由簡(jiǎn)單傳統(tǒng)的方法調(diào)用組成，因此不會(huì)有運(yùn)行時(shí)的開(kāi)支負(fù)擔(dān)。在Java生態(tài)系統(tǒng)中***的模塊框架是OSGi。它是一個(gè)成熟的規(guī)范，具有幾個(gè)不同的實(shí)現(xiàn)。在OSGi中，模塊被稱作bundle，每個(gè)bundle等同于一個(gè)JAR。每個(gè)bundle也包含一個(gè) META-INF/MANIFEST.MF文件，這個(gè)文件會(huì)宣布導(dǎo)出哪些包(package)以及導(dǎo)入哪些包。只有那些導(dǎo)出包中的類才能被其他 bundle所使用，而其他包都只面向包的內(nèi)部成員，包里的類也只能在自身bundle中使用。

比如下面這個(gè)聲明：

Manifest-Version: 1.0

Import-Package: net.krecan.spring.osgi.common

Export-Package: net.krecan.spring.osgi.dao

Bundle-Version: 1.0.0

Bundle-Name: demo-spring-osgi-dao

Bundle-SymbolicName: net.krecan.spring-osgi.demo-spring-osgi-dao

這個(gè)規(guī)范指定了名叫demo-spring-osgi-dao的bundle，它要導(dǎo)入包名為 net.krecan.spring.osgi.common中的類，并導(dǎo)出包名為net.krecan.spring.osgi.dao中的類。換句話說(shuō)，這段聲明表明其他模塊只能使用net.krecan.spring.osgi.dao包。相反地，這個(gè)模塊要使用的則只是 net.krecan.spring.osgi.common包，而且也可能會(huì)由OSGi來(lái)提供專門(mén)的模塊負(fù)責(zé)導(dǎo)出這個(gè)包。當(dāng)然你完全可以在導(dǎo)入和導(dǎo)出聲明中定義多個(gè)包名。

需要特別注意的是，OSGi的模塊化是構(gòu)建在Java之上的。它不是語(yǔ)言的一部分!這里的模塊分離雖然可以由GUI來(lái)執(zhí)行，但不可以由編譯器來(lái)執(zhí)行。運(yùn)行基于OSGi的應(yīng)用時(shí)，你會(huì)需要一個(gè)OSGi的容器。這個(gè)容器可能是運(yùn)行時(shí)環(huán)境的一部分，比如在Spring DM服務(wù)器中，也可能是嵌入在應(yīng)用程序中的。這個(gè)容器不僅負(fù)責(zé)提供分離，也提供了其他諸如安全、模塊管理和生命周期管理之類的服務(wù)。OSGi還提供大量其他有趣的特性，但這些并不是本文所要關(guān)注的。

關(guān)于JSR-277曾經(jīng)有很多爭(zhēng)議，這個(gè)JSR一度跟OSGi有部分重復(fù)。連續(xù)好幾個(gè)月，雙方的專家都極力辯論誰(shuí)更優(yōu)秀，直到JSR-277被宣布放棄，而新的模塊系統(tǒng)將會(huì)是Java 7的一部分。

JSR-294

這個(gè)新的模塊系統(tǒng)的***部分就是JSR-294，即所謂的超級(jí)包。也正是這個(gè)規(guī)范闡釋了Java語(yǔ)言的模塊部分的概念。

JSR-294引入了新的可見(jiàn)性關(guān)鍵字“module”。如果一個(gè)成員擁有這樣的可見(jiàn)性，那就意味著它只對(duì)同一模塊中的成員可見(jiàn)。它會(huì)創(chuàng)建一個(gè)內(nèi)部的 API，只有模塊本身能調(diào)用。就此看來(lái)，“public”關(guān)鍵字應(yīng)當(dāng)只在聲明一個(gè)公共的API時(shí)才用。而在其他情況下，應(yīng)當(dāng)使用“module”或者有更多限制的可見(jiàn)性關(guān)鍵字。當(dāng)然，一旦語(yǔ)言中有了“module”關(guān)鍵字，那么模塊之間的可見(jiàn)性限制將會(huì)由編譯器來(lái)負(fù)責(zé)檢查。

JSR-294也允許定義依賴性。你可以在某個(gè)給定版本中，定義某個(gè)模塊依賴于另一模塊。比如：

//org/netbeans/core/module-info.java

@Version("7.0")

@ImportModule(name="java.se.core", version="1.7+")

module org.netbeans.core;

***一句表明“org.netbeans.core”模塊依賴“java.se.core”的1.7版本或者更高。這類似于Maven的依賴性或者 OSGi的導(dǎo)入。你也可以暫時(shí)不要管這些語(yǔ)法，因?yàn)閷?lái)語(yǔ)法可能會(huì)另有變化。重要的是，這兒的依賴是在module-info.java中定義的，會(huì)被編譯成class文件。而OSGi中，依賴則是在普通的文本文件中定義的。

Jigsaw項(xiàng)目

Jigsaw項(xiàng)目是這個(gè)新模塊系統(tǒng)的第二部分。我預(yù)計(jì)它會(huì)是JSR-294特定于Sun的實(shí)現(xiàn)，也會(huì)是Sun JDK的模塊化實(shí)現(xiàn)。既然創(chuàng)建完整的JDK模塊化是有必要的，Sun就希望把標(biāo)準(zhǔn)庫(kù)分裝成模塊。這直接簡(jiǎn)化了JRE中的內(nèi)容整合。整個(gè)JRE除了Swing之外的所有內(nèi)容因此都能夠在移動(dòng)設(shè)備上運(yùn)行。它還有可能為語(yǔ)言引入新的標(biāo)準(zhǔn)API，而無(wú)需再等待整個(gè)平臺(tái)的新版本發(fā)布。目前看起來(lái)，這個(gè)項(xiàng)目絕對(duì)有希望實(shí)現(xiàn)。

但我對(duì)此還有個(gè)擔(dān)憂，那就是，a >專有的Jigsaw和JSR標(biāo)準(zhǔn)之間的關(guān)系并不清晰，正如Mark Reinhold所說(shuō)的：

對(duì)Jigsaw的投入無(wú)疑會(huì)創(chuàng)建出一個(gè)簡(jiǎn)單的、低層次的模塊系統(tǒng)，它的設(shè)計(jì)會(huì)嚴(yán)格地朝著JDK模塊化的目標(biāo)而發(fā)展。開(kāi)發(fā)人員可以把這個(gè)模塊系統(tǒng)運(yùn)用到他們的代碼中去，Sun對(duì)這個(gè)模塊系統(tǒng)也會(huì)是絕對(duì)的支持，但它不會(huì)是Java SE 7平臺(tái)規(guī)范的官方部分，也可能不會(huì)被其他SE 7實(shí)現(xiàn)所支持。

這段話說(shuō)的不是很清楚，當(dāng)中有很多疑問(wèn)。他的意思是說(shuō)創(chuàng)建的模塊只能在Sun JRE中運(yùn)行嗎?還是想說(shuō)，如果開(kāi)發(fā)者寫(xiě)了“@ImportModule(name="java.se.core", version="1.7+")”，那么這個(gè)模塊只能在Sun JRE中運(yùn)行，而不能在IBM JRE環(huán)境中運(yùn)行嗎?或者他的意思是不是說(shuō)Sun會(huì)以某種方式把它的JRE分割成許多模塊，而Oracle會(huì)選擇另外的方式去分割嗎?(譯者注：至少現(xiàn)在看來(lái)，不太會(huì)有這樣的可能了，因?yàn)镺racle剛剛收購(gòu)了Sun)。我們希望都不是，因?yàn)檫€有“編寫(xiě)一次，到處運(yùn)行”的原則。

細(xì)究起來(lái)問(wèn)題更多。我們并不清楚Jigsaw項(xiàng)目的主要目標(biāo)是什么。據(jù)項(xiàng)目本身所宣布的主要目標(biāo)來(lái)看，它要實(shí)現(xiàn)的是Sun JRE的模塊化，但如果純粹是要實(shí)現(xiàn)模塊化的話，就不需要對(duì)語(yǔ)言做任何改變。Sun可以對(duì)JRE進(jìn)行模塊化，而不修改Java語(yǔ)言本身。

這些語(yǔ)言上的變化會(huì)不會(huì)成為Sun JRE模塊化帶來(lái)的副產(chǎn)品?如果是，那就徹底錯(cuò)了!語(yǔ)言變化必須是一等公民，而不是專屬的副產(chǎn)品。

依賴

我的另外一個(gè)擔(dān)心在于依賴性。如果依賴性由模塊系統(tǒng)來(lái)管理，那就不再需要classpath了。一方面這很不錯(cuò)，因?yàn)閏lasspath經(jīng)常會(huì)導(dǎo)致所謂的JAR地獄問(wèn)題。但另一方面，classpath也是極度靈活的，我恐怕這種靈活性是不可能由一個(gè)靜態(tài)的模塊依賴能夠擁有的。讓我們來(lái)看看為什么：

部署時(shí)依賴

Java中有兩種類路徑(classpath)。一個(gè)是構(gòu)建路徑(buildpath)，它用在構(gòu)建時(shí)。另外一個(gè)是類路徑，用在運(yùn)行時(shí)。兩者幾乎相同，但又不完全是。經(jīng)典的例子就是JDBC驅(qū)動(dòng)。在構(gòu)建時(shí)，你不需要指定JDBC驅(qū)動(dòng)，JDBC接口是Java核心庫(kù)的一部分。但在運(yùn)行時(shí)，你就有必要確保類路徑中有JDBC的驅(qū)動(dòng)。如果某個(gè)編程人員需要修改數(shù)據(jù)庫(kù)連接，他只需要在配置文件中修改驅(qū)動(dòng)類的名稱，并把驅(qū)動(dòng)jar文件添加到類路徑就可以了。如果所有的依賴需要在編譯時(shí)指定，開(kāi)發(fā)者很明顯無(wú)法做到這點(diǎn)。當(dāng)然，在Java EE中，他可以使用JNDI數(shù)據(jù)源，但在Java SE中沒(méi)有類似的東西，一旦修改JDBC驅(qū)動(dòng)，就不得不重新編譯整個(gè)應(yīng)用，這明顯很不靠譜。

通常來(lái)說(shuō)，重新編譯不太可能。在一些組織中，最終的應(yīng)用是由所謂的應(yīng)用裝配器的模塊組裝而成的。開(kāi)發(fā)者沒(méi)有源代碼，他只是把一些JAR放在一起，修改一下配置文件，然后創(chuàng)建最終的包。應(yīng)用裝配器的角色甚至在Java EE的規(guī)范中都有提到。

可選依賴

類似的問(wèn)題就是可選依賴。我們假設(shè)我們要做一個(gè)像log4j這樣的日志框架。這個(gè)庫(kù)可以對(duì)JMS記錄日志，因此JMS包必須涵蓋在構(gòu)建路徑中。但99%的用戶并不使用JMS日志，因此他們不需要把依賴放在類路徑中。對(duì)于這樣的問(wèn)題，必須要有某種機(jī)制來(lái)解決。我們需要一個(gè)庫(kù)來(lái)構(gòu)建這個(gè)模塊，這種依賴對(duì)最終用戶來(lái)說(shuō)則是可選的。當(dāng)然，***的情況是，JMS功能會(huì)是個(gè)獨(dú)立模塊，可我們并不是生活在一個(gè)***的世界，而且某些時(shí)候用這種方式來(lái)分割項(xiàng)目也不太現(xiàn)實(shí)。

依賴沖突

另外一個(gè)大問(wèn)題就是依賴沖突。如果你用過(guò)Maven，就不難理解我在說(shuō)什么了。大多數(shù)企業(yè)應(yīng)用都會(huì)用到大約十幾個(gè)第三方庫(kù)，它們之間的互相依賴有時(shí)就會(huì)發(fā)生沖突。比如，一個(gè)開(kāi)發(fā)者想要使用Hibernate，它依賴commons-collections 2.1.1，他還想用commons-dbcp，卻需要依賴commons-collections 2.1。開(kāi)發(fā)者自己或者應(yīng)用裝配器需要決定怎樣解決此類問(wèn)題。他要么決定在應(yīng)用中只用某個(gè)特定版本的庫(kù)，要么決定在應(yīng)用的不同部分采用不同版本的類庫(kù)。重要的是，這些問(wèn)題無(wú)法自行解決。它總需要由某個(gè)了解各個(gè)模塊在應(yīng)用中如何運(yùn)作的人來(lái)作決定，而這個(gè)人又要能識(shí)別不同版本間可能存在的不兼容性。

關(guān)于Java依賴性，還有許多東西本文不展開(kāi)討論，但需要銘記的一點(diǎn)是，它們不是靜態(tài)的。一個(gè)應(yīng)用的構(gòu)件可能采用了某套類庫(kù)，而它的運(yùn)行卻需要另外一套完全不同的庫(kù)。所有模塊系統(tǒng)必須以某種方式把這些問(wèn)題解決掉。Maven具有大量關(guān)于如何配置依賴，以及如何處理依賴沖突等等的選項(xiàng)，但它只是個(gè)構(gòu)建系統(tǒng)。最糟糕的情況是需要手動(dòng)配置類路徑。OSGi則是另外一種情形。它只處理運(yùn)行時(shí)(部署時(shí))依賴，不管構(gòu)建時(shí)。新的Java模塊系統(tǒng)會(huì)同時(shí)支持構(gòu)建時(shí)和運(yùn)行時(shí)依賴(我猜測(cè))，甚至?xí)鸭扔械膹?fù)雜問(wèn)題變得愈加復(fù)雜。

看完上述內(nèi)容是否對(duì)您有幫助呢？如果還想對(duì)相關(guān)知識(shí)有進(jìn)一步的了解或閱讀更多相關(guān)文章，請(qǐng)關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道，感謝您對(duì)創(chuàng)新互聯(lián)的支持。