走進Java 7模組系統

筆者在觀看過Devoxx關於Jigsaw的一段示範後，我很興奮，覺得它應該會是針對複雜類路徑版本問題和JAR陷阱等問題的解決方案。開發人員最終能夠使用他們所期望的任何Xalan版本，而無需被迫使用授權機制。不幸的是，通往更加有效模組系統的征途並不是很清晰。

　　在研究確實問題之前，我們先來看一些基本概念：

　　模組化

　　模組化

　　是解決複雜性問題很重要的工具。把應用分成不同的部分(模組、庫、包、子項目和組件)，再分別進行計算，是行之有效方式。模組化的最終目的是能定義出一套API用於模組間的溝通。

　　如果模組間所有的通訊都只通過這種API來實現，那麼模組是松耦合的，於是：

　　改變某個模組的實現會很容易

　　開發與測試各個模組能很容易獨立開來

　　物件導向模式也是類似的道理。在OOP中，理想的狀況是擁有大量小的、可重用的、簡單並分離良好的對象。在模組系統中，就可以完美地實現小的、可重用的、簡單並分離良好的模組。它們的想法和最初的動機是完全一樣的，只是規模有所不同。

　　邏輯分離

　
　傳統上，Java中有兩種辦法來實現模組化。邏輯分離是最自然的方式。它包括將應用程式分割成邏輯模組(子項目)，最後再部署成一個完整的應用。通過定
義正確的包來實現邏輯分離也是可能的，但更通用的辦法是把應用分割成一些封存檔案(也就是JAR包)。邏輯分離裡能促進模組的重用，有助實現模組間的松耦
合。你甚至有可能定義一個API，然後宣布所有模組間的通訊都要通過這個給定的API來實現。這樣的想法有個大問題，那就是你很難強破大家都採用這種限制
性用法，而且沒有任何一種機制能夠確保這個API的用法。你也沒法把那些應用通過給定模組來使用的類和作為公用API一部分的類區分開來。如果一個類是“
公用的”，那它就可以被任何其他類使用，無論調用它的那個類屬於哪個模組。另一方面，受保護的或者包級可見度的類在其模組內部的調用也有限制。通常來說，
涵蓋了一些包以及包中類的模組需要能夠互相調用。因此即使某個應用是由一些邏輯模組組成，但如果這些模組是耦合的，那麼分離也根本沒有用處。

　　物理分離

　
　另外一個傳統的辦法就是物理上的分離。你可以通過將應用分割成不同的組件，然後把每個組件部署到不同的JVM上而實現分離。這些組件間通過遠端存取機制
進行通訊，比如RMI、CORBA或者WebServices。物理分離實現了分離，也實現了松耦合，但負面影響是開支很大。為實現分離而專門採用遠程訪
問機制，有點殺雞用牛刀的味道。這會增加開發和部署不必要的複雜性，效能上所受到的影響也不能忽視的。

　　模組系統

　　模組系統

　
　的作用位於邏輯分離和物理分離之間。它強調模組分離，但各個模組仍然部署到同一個JVM中，而且模組間的通訊由簡單傳統的方法調用組成，因此不會有運行
時的開支負擔。在Java生態系統中最流行的模組架構是OSGi。它是一個成熟的規範，具有幾個不同的實現。在OSGi中，模組被稱作bundle，每個
bundle等同於一個JAR。每個bundle也包含一個META-INF/MANIFEST.MF檔案，這個檔案會宣布匯出哪些包(package)
以及匯入哪些包。只有那些匯出包中的類才能被其他bundle所使用，而其他包都只面向包的內部成員，包裡的類也只能在自身bundle中使用。

　　比如下面這個聲明：

　　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

　
　這個規範指定了名叫demo-spring-osgi-dao的bundle，它要匯入包名為
net.krecan.spring.osgi.common中的類，並匯出包名為net.krecan.spring.osgi.dao中的類。換句話
說，這段聲明表明其他模組只能使用net.krecan.spring.osgi.dao包。相反地，這個模組要使用的則只是
net.krecan.spring.osgi.common包，而且也可能會由OSGi來提供專門的模組負責匯出這個包。當然你完全可以在匯入和匯出聲
明中定義多個包名。

　　需要特別注意的是，OSGi的模組化是構建在Java之上的。它不是語言的一部分!這裡的模組分離雖然可以由GUI
來執行，但不可以由編譯器來執行。運行基於OSGi的應用時，你會需要一個OSGi的容器。這個容器可能是運行時環境的一部分，比如在SpringDM服
務器中，也可能是嵌入在應用程式中的。這個容器不僅負責提供分離，也提供了其他諸如安全、模組管理和生命週期管理之類的服務。OSGi還提供大量其他有趣
的特性，但這些並不是本文所要關注的。

　　關於JSR-277曾經有很多爭議，這個JSR一度跟OSGi有部分重複。連續好幾個月，雙方的專家都極力辯論誰更優秀，直到JSR-277被宣布放棄，而新的模組系統將會是Java7的一部分。

　　JSR-294

　　這個新的模組系統的第一部分就是JSR-294，即所謂的超級包。也正是這個規範闡釋了Java語言的模組部分的概念。

　　JSR-294

　
　引入了新的可見度關鍵字“module”。如果一個成員擁有這樣的可見度，那就意味著它只對同一模組中的成員可見。它會建立一個內部的API，只有模組
本身能調用。就此看來，“public”關鍵字應當只在聲明一個公用的API時才用。而在其他情況下，應當使用“module”或者有更多限制的可見度關
鍵字。當然，一旦語言中有了“module”關鍵字，那麼模組之間的可見度限制將會由編譯器來負責檢查。

　　JSR-294

　　也允許定義依賴性。你可以在某個給定版本中，定義某個模組依賴於另一模組。比如：

　　//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的匯入。你也可以暫時不要管這些文法，因為將來文法可能會另有變化。重要的是，這兒的依賴是在module-info.java中定義的，會被編
譯成class檔案。而OSGi中，依賴則是在普通的文字檔中定義的。

　　Jigsaw項目

　　Jigsaw項目

　
　是這個新模組系統的第二部分。我預計它會是JSR-294特定於Sun的實現，也會是SunJDK的模組化實現。既然建立完整的JDK模組化是有必要
的，Sun就希望把標準庫分裝成模組。這直接簡化了JRE中的內容整合。整個JRE除了Swing之外的所有內容因此都能夠在行動裝置上運行。它還有可能
為語言引入新的標準API，而無需再等待整個平台的新版本發布。目前看起來，這個項目絕對有希望實現。

　　但我對此還有個擔憂，那就是，ahref="http://blogs.sun.com/mr/entry/jigsaw">專有的Jigsaw和JSR標準之間的關係並不清晰，正如MarkReinhold所說的：

　
　對Jigsaw的投入無疑會建立出一個簡單的、低層次的模組系統，它的設計會嚴格地朝著JDK模組化的目標而發展。開發人員可以把這個模組系統運用到他
們的代碼中去，Sun對這個模組系統也會是絕對的支援，但它不會是JavaSE7平台規範的官方部分，也可能不會被其他SE 7實現所支援。

　
　這段話說的不是很清楚，當中有很多疑問。他的意思是說建立的模組只能在SunJRE中運行嗎?還是想說，如果開發人員寫了
“@ImportModule(name="java.se.core",version="1.7+")”，那麼這個模組只能在SunJRE中運行，而
不能在IBMJRE環境中運行嗎?或者他的意思是不是說Sun會以某種方式把它的JRE分割成許多模組，而Oracle會選擇另外的方式去分割嗎?(譯者
註：至少現在看來，不太會有這樣的可能了，因為Oracle剛剛收購了Sun)。我們希望都不是，因為還有“編寫一次，到處運行”的原則。

　　細究起來問題更多。我們並不清楚Jigsaw項目的主要目標是什麼。據項目本身所宣布的主要目標來看，它要實現的是SunJRE的模組化，但如果純粹是要實現模組化的話，就不需要對語言做任何改變。Sun可以對JRE進行模組化，而不修改Java語言本身。

　　這些語言上的變化會不會成為SunJRE模組化帶來的副產品?如果是，那就徹底錯了!語言變化必須是一等公民，而不是專屬的副產品。

　　依賴

　
　我的另外一個擔心在於依賴性。如果依賴性由模組系統來管理，那就不再需要classpath了。一方面這很不錯，因為classpath經常會導致所謂
的JAR地獄問題。但另一方面，classpath也是極度靈活的，我恐怕這種靈活性是不可能由一個靜態模組依賴能夠擁有的。讓我們來看看為什麼：

　　部署時依賴

　
　Java中有兩種類路徑(classpath)。一個是構建路徑(buildpath)，它用在構建時。另外一個是類路徑，用在運行時。兩者幾乎相同，
但又不完全是。經典的例子就是JDBC驅動。在構建時，你不需要指定JDBC驅動，JDBC介面是Java核心庫的一部分。但在運行時，你就有必要確保類
路徑中有JDBC的驅動。如果某個編程人員需要修改資料庫連接，他只需要在設定檔中修改驅動類的名稱，並把驅動jar檔案添加到類路徑就可以了。如果所
有的依賴需要在編譯時間指定，開發人員很明顯無法做到這點。當然，在JavaEE中，他可以使用JNDI資料來源，但在JavaSE中沒有類似的東西，一旦修改
JDBC驅動，就不得不重新編譯整個應用，這明顯很不靠譜。

　　通常來說，重新編譯不太可能。在一些組織中，最終的應用是由所謂的應用裝配器的模組組裝而成的。開發人員沒有原始碼，他只是把一些JAR放在一起，修改一下設定檔，然後建立最終的包。應用裝配器的角色甚至在JavaEE的規範中都有提到。

　　可選依賴

　
　類似的問題就是可選依賴。我們假設我們要做一個像log4j這樣的日誌架構。這個庫可以對JMS記錄日誌，因此JMS包必須涵蓋在構建路徑中。但99%
的使用者並不使用JMS日誌，因此他們不需要把依賴放在類路徑中。對於這樣的問題，必須要有某種機制來解決。我們需要一個庫來構建這個模組，這種依賴對最終
使用者來說則是可選的。當然，完美的情況是，JMS功能會是個獨立模組，可我們並不是生活在一個完美的世界，而且某些時候用這種方式來分割項目也不太現實。

　　依賴衝突

　
　另外一個大問題就是依賴衝突。如果你用過Maven，就不難理解我在說什麼了。大多數公司專屬應用程式都會用到大約十幾個第三方庫，它們之間的互相依賴有時就會
發生衝突。比如，一個開發人員想要使用Hibernate，它依賴commons-collections2.1.1，他還想用commons-dbcp，
卻需要依賴commons-collections2.1。開發人員自己或者應用裝配器需要決定怎樣解決此類問題。他要麼決定在應用中只用某個特定版本的
庫，要麼決定在應用的不同部分採用不同版本的類庫。重要的是，這些問題無法自行解決。它總需要由某個瞭解各個模組在應用中如何運作的人來作決定，而這個人
又要能識別不同版本間可能存在的不相容性。

　　關於Java依賴性，還有許多東西本文不展開討論，但需要銘記的一點是，它們不是靜態。一
個應用的構件可能採用了某套類庫，而它的運行卻需要另外一套完全不同的庫。所有模組系統必須以某種方式把這些問題解決掉。Maven具有大量關於如何配置
依賴，以及如何處理依賴衝突等等的選項，但它只是個構建系統。最糟糕的情況是需要手動設定類路徑。OSGi則是另外一種情形。它只處理運行時(部署時)依
賴，不管構建時。新的Java模組系統會同時支援構建時和運行時依賴(我猜測)，甚至會把既有的複雜問題變得愈加複雜。

　　總結

　
　當然，我相信Sun的工程師並不想要破壞Java本身。我想他們也是為了讓Java變得更好、更便於使用，但我擔心政治和市場因素會遠大於技術影響。再
次聲明，這不會僅僅是個API的變化或者是特定於Sun的變化。這會是語言層級的變化!一旦語言被改變了，一旦添加了“module”關鍵字，就不會再有
回頭路。到那時，Java中會有個模組系統，無論喜不喜歡，我們都非得要用到這個模組系統。真得很難想象帶模組化的JVM，也很難想像Java語言中會有
個“module”關鍵字，而我們還要在這之上使用OSGi。

轉自：http://it.hexun.com/2009-05-14/117684830.html