從Java 7開始,就一直嚷嚷著要納入的模組化架構,到了Java 8不見推出,這中間又過了好幾年,最後來到了Java 9,而Java 9又因開發不及,從原定的2017年3月改到了2017年7月,如果沒有意外,目前看來,應該是可以如期推出。

而在最新的JDK9預覽版中,也可以玩玩Java模組平臺系統(Java Platform Module System),也就是JSR376的實作了。

JAR檔案的挑戰

撰寫Java的開發者都知道,目前的Java使用JAR檔案來包裝一堆類別檔案,而這些類別檔案會使用套件(package)來加以組織,在編譯或運行Java應用程式時,必須指定類別路徑(CLASSPATH),一開始這不是什麼問題,只是隨著Java應用的場合越來越多,挑戰也就越來越多。

舉例而言,JAR檔案定義在類別路徑中的順序,經常會有同名類別遮蓋的問題;JAR對包裝的類別沒有封裝機制,即使開發中的程式庫想隱藏底層使用到的實作品,然而,只要是public的類型,對客戶端就是可見的;簡而言之,JAR檔案充其量只是個方便傳送的器皿罷了,它沒辦法表示彼此之間的依賴關係,想想看,有多少次發生ClassNotFoundException時,你總是想不透,到底還缺少了哪個JAR檔案呢?

Java SE自己也身受其害。從10MB以下的JDK1.1,到現在200多MB的JDK8,JDK越來越肥大,在錯綜複雜的依賴關係下,有些標準API就算不需要,也必須全盤接受,這對現今的IoT是個挑戰,雖然Java 8之後有了compact profile,可定義三種Java SE的子集,然而,也只是在有限程度下緩解了這個問題。

而且,還有更多其他的問題待解決,這部份可以參考〈Project Jigsaw is Really Coming in Java 9〉(https://goo.gl/15XuYl),某些工具試圖解決部份問題,像是Maven、OSGi等,然而由於一些技術、政治或商業性考量,Java 9終究是採用了Jigsaw來解決(部份的)問題。

類別路徑淡出,模組路徑登場

具體來說,Java 9中的模組仍是使用JAR檔案,這是為了善用現有的工具,以緩解導入或遷移的負擔,一個模組化JAR檔案(modular JAR file)與一般JAR檔案之間的差別,在於根目錄下是否包含一個module-info.class,而它又是由一個module-info.java檔案編譯而來,這個.java是作為模組描述器(Module descriptor)使用。

一個最簡單的模組描述器,可以只包括module cc.openhome.app {}這樣的內容,雖然是個.java檔案,但它不是Java原始碼,開發者不用擔心module成為保留字,而影響了既有的Java原始碼,因為這一個不是Java的.java,以及編譯出來的.class,只是讓編譯器或執行環境能理解這是一個模組。

模組名稱必須是唯一的,與套件名稱類似的,建議使用網域名稱的相反模式,通常是套件名稱的前置部份,如果應用程式依賴在某些模組,在編譯的時候,必須使用--module-path(簡寫-p)或--module-source-path來指定模組路徑,執行時也要指定--module-path,或者是在想要指定起始模組時使用--module(簡寫-m)。

在Java 9推出之後,未來在開發上當然是鼓勵定義模組的,而類別路徑的指定方式,基於向後相容性(Backward compatibility)考量仍舊支援,實際上,一個模組化JAR檔案若是指定於類別路徑中,就會被當成是一般JAR檔案,然而,類別路徑未來應走向逐漸淡出的道路,既有的程式庫在可能的情況下,也要逐漸遷移至新的模組系統。

模組描述器概觀

最簡單的module-info.java,可以只包括module cc.openhome.app {},這樣的模組描述器沒有指定任何依賴模組,這表示它依賴在最基本的java.base模組(若使用到java.sql等其他模組,就會編譯失敗)。Java SE 9將過往有著錯綜複雜依賴關係的標準API,畫分為java.logging、java.sql、java.xml等各個模組,而這些模組最終都依賴在一個java.base模組,它包含了java.lang、java.io等基本套件,而整個Java SE被定義為一個java.se模組。

一個有著依賴關係的模組描述器,會像是:

module cc.openhome.app {
requires cc.openhome.openscad;
requires public cc.openhome.math;
exports cc.openhome.turtle;
}

這部分表示了一些事情——cc.openhome.app模組依賴在cc.openhome.openscad,以及前者的類別對後者匯出(exports)的公開類別,具有讀取性(Readability)。而且,要注意的是,讀取性僅定義了模組的依賴關係圖,例如cc.openhome.app對cc.openhome.openscad是顯式(explicitly)依賴,然而,cc.openhome.openscad可能依賴在其他模組上,因而這些模組也被cc.openhome.app隱式(implicitly)依賴,而對於module cc.openhome.app {},它也隱式依賴在java.base。

只有讀取性,並不代表著可使用被依賴模組中的類別,例如,若有模組requires cc.openhome.app,而上面的模組描述器中並沒有exports cc.openhome.turtle的話(cc.openhome.app中定義的套件),那麼就無法使用cc.openhome.turtle套件中的類別,這表示被public定義的類別不再是全域可見了,定義模組時可以使用exports決定其存取性(Accessibility),因而模組可以實現更強的封裝性(Strong encapsulation)。

有一個問題是,如果有模組requires cc.openhome.app,而cc.openhome.openscad模組中,傳回了cc.openhome.math套件中的類別類型,那麼,最前頭的模組可以也使用該類型嗎?

對此,簡單的想法是,讓開發者自行在一開始的模組描述器,也加上requires cc.openhome.openscad,不過,這作法麻煩也不可靠,如果cc.openhome.app願意的話,只要加上requires public cc.openhome.math,就可以解決這個問題。

相容性與遷移

無疑地,既有的應用程式,還是要能在Java 9上運行的,其中一個作法如前所述,一個模組化JAR檔案若是指定於類別路徑中,會被當成是一般JAR檔案,實際上,置於類別路徑中的類別,都會被歸類在一個未命名模組(unnamed module),未命名模組對任何模組都具有讀取性,對被模組匯出的套件中的任何類別具有存取性。

而在既有程式庫的遷移上,有一個簡單的情境是,如果某個JAR檔案未依賴類別路徑上的其他程式庫,而且經檢查僅依賴在java.base模組,那麼,這個JAR檔案可以進一步定義為模組化檔案;接著,若另一個JAR檔案依賴在這個JAR,就可以定義其依賴在新定義的模組,以及其他的java.sql等模組上,依此類推、完成遷移。整體而言,這是一種自底而上的遷移(Bottom-up migration)方式。

當然,實際的依賴情況可能更複雜,可以使用jdeps之類的工具來檢查相依關係,而開發者也需要瞭解更多模組化的細節,此時,Simon Ritter的演講〈Project Jigsaw in JDK 9: Modularity Comes To Java〉(https://goo.gl/3Scf6n)會是個好的開始。

在這之後,OpenJDK官方的〈The State of the Module System〉(https://goo.gl/HFN9Em)是個詳盡的文件。

作者簡介


Advertisement

更多 iThome相關內容