Mark Reinhold前些天公布了Java模塊化的第一份公開草案.正如Mark在有關這個問題的博客里說的,這次關於Java模塊化的討論和先前的JSR294迭代有所不同,這次討論不是Sun/Oracle關起門來進行的,而是引入了參與OpenJDK的其他成員,比如IBM,還有Java SE和Java EE社區的其他成員.
由於這只是一份草案,有些問題仍然需要商討,但它已經對什麼是Java模塊化進行了統一的定義.有IBM的參與,這份草案比以往更加關注與OSGi之間的互操作性.
有個比較有意思的需求是,即便ServiceLoader和ResourceBundle在Java模塊化里的表現並不盡如人意,但模塊化還是想基於這兩部分內容構建,以便那些想用標準模式的開發人員不用關注細節就可以利用模塊化.目前,ServiceLoader在處理多個類載入器的時候還有問題.
讓JVM模塊化的主要目的之一是對JVM庫進行分割,JVM庫這些年已經增長到了幾十兆.（不處理模塊化概念的Scala也已經有十兆了）.不過JVM庫里所有的類都在同一個類載入器里；而OSGi是每個Bundle有一個類載入器,這就不能進行直接的映射.（OSGi有片段的概念,片段能把自己寫到父類載入器里去）.文檔里有一部分需求定義到,要支持有單獨類載入器的模塊系統和提供多個類載入器方法的模塊系統.
文檔里有些描述還比較模糊.比如說,要求版本完全有序,但似乎還沒有像Semantic Versioning這樣一致的版本化方法.此外,文檔要求嚴格定義元數據（版本號是其中一部分）,而版本的概念還有待商榷.
另一個懸而未決的問題是,模塊信息是否應該像編譯好的Java代碼或可聲明的外部庫那樣使用.OSGi利用已有的MANIFEST.MF文件處理編碼依賴,先前的Jigsaw實現則編譯一個Java類文件,允許通過庫進行內省.這對Java變種有一個不利影響,就是Mirah或JRuby等非Java語言使用模塊系統會更加困難.
這個需求貌似還有較大爭議.雖然JRuby的領導者Charles Nutter說他還沒來得及閱讀完整的規範,但他在Reinhold的博客里評論說
Jigsaw模塊化系統要求有一個可能包含註解的.class文件,因此也沒必要限制參與語言：
發布前要先編譯成JVM位元組碼
支持全部的Java語言結構,比如源碼級的註解
換句話說,JRuby、JavaScript（Rhino）、各個版本的Smalltalk、Python（Rhino）及其它幾種語言會立即被排除在外了.
提案還談到了通用打包系統（比如rpm和easy_install）,藉助這類系統可以把Java運行時傳遞給其他系統和已在網路上發布的工件.和模塊化相比,對這部分的論述要稍微深入一點兒.
這份提案雖然尚未完成、還有待解決的問題,但已經收到了一些積極的反饋：
文檔里還有很多很多好的需求,這些需求要是都能以開放和兼容的方式實現,Java一定會從中獲益.
另一個好處是,一旦模塊化成為Java SE 8的一部分,向OSGi轉會比現在容易得多.現在要想把已有系統往OSGi上遷移,最大的障礙往往是系統的模塊化,
系統最初就不是以模塊的方式構建的.這不是OSGi本身的問題,而是模塊化概念的問題.你要是有非模塊化的代碼,就很難對它們進行模塊化.在Java SE 8里,這個問題會在開發周期的更早期出現,這有助於開發人員從一開始就用模塊的方式去設計系統.如果基本的JVM模塊系統不能滿足你的需求,你可以把已有的Java SE 8模塊轉到OSGi上,這些模塊還會按原來的樣子運行,
遷移變得輕而易舉.然後你就可以利用OSGi的優勢對模塊進行增強了.
Java的模塊化可能會使OSGi-lite模式成為現實,會鼓勵Java庫的開發人員使用模塊元數據對他們的運行時進行註解,而這些元數據都能被OSGi運行時使用.在任何情況下,就算有一些已知的分歧,只要用一種兼容而合理的方式前進,對所有Java（和基於Java）的開發人員就都有好處.
