1 JDK 先生有點(diǎn)煩

JDK先生有點(diǎn)煩， 因?yàn)樽罱鼛讉€(gè)刺兒頭程序經(jīng)常找茬兒， 抱怨的還是classpath, jar 文件, package這幾個(gè)JDK賴以生存、 引以為傲的基礎(chǔ)設(shè)施。

想當(dāng)年java誕生的時(shí)候， package 幫助程序員把java 類更好地組織起來(lái)， jar 文件把class文件打成壓縮包，而classpath 這么多年一直兢兢業(yè)業(yè)地查找類文件，從來(lái)沒(méi)出過(guò)差錯(cuò)。 為啥要抱怨他們呢?

前天用戶系統(tǒng)跑過(guò)來(lái)說(shuō)，他有兩個(gè)package ，com.foo.db.api.和 com.foo.db.impl, 他期望大家只使用api包的UserDao, 可是總有一些不著調(diào)的程序員還去直接使用impl包, 屢禁不止啊。

用戶系統(tǒng)帶著怨氣地問(wèn)道： 你就沒(méi)有辦法讓impl包也變成對(duì)外私有的? 你要是再不支持，我們都要轉(zhuǎn)到OGSi 去了啊，到時(shí)候你后悔都來(lái)不及!

還有，昨天訂票系統(tǒng)跑來(lái)說(shuō)，他有兩個(gè)模塊，模塊A 依賴json_1.1.jar，模塊B依賴 json_2.0.jar , 可是這兩個(gè)jar 互不兼容， 怎么把它們放到classpath上?

JDK 覺(jué)得訂票系統(tǒng)很變態(tài)，怎么會(huì)出現(xiàn)這樣的代碼，這不是自己折磨自己?jiǎn)? 但轉(zhuǎn)念一想，主要的問(wèn)題還是自己的classpath, 這個(gè)所謂的classpath 是個(gè)平鋪的線性結(jié)構(gòu)， 而jar 之間的依賴關(guān)系應(yīng)該是個(gè)有向圖啊!

今天還有個(gè)家伙說(shuō)他要開(kāi)發(fā)物聯(lián)網(wǎng)應(yīng)用， 內(nèi)存受限， 他發(fā)現(xiàn)JDK和JRE太大了，動(dòng)輒上百M(fèi)， 更要命的是其中有不少東西他們并不用， 例如界面相關(guān)的jar , 但是又沒(méi)法從JDK中去除。 能不能按照需要裁剪一下JDK呢?

如果說(shuō)前面兩個(gè)要求還算合理， 這個(gè)老兄的要求簡(jiǎn)直就是一場(chǎng)革命， JDK自己革自己的命。

2 模塊化

雖然JDK已經(jīng)非常成熟，但是用戶的需求不能置之不理。

JDK閉關(guān)思考了半月， 終于憋出來(lái)一個(gè)大招：做粗粒度的模塊化!

他把各位刺兒頭招來(lái)商議。

“模塊化? 還粗粒度? ”　一聽(tīng)到這個(gè)消息，　訂單系統(tǒng)就跳了起來(lái)，生怕把自己給改亂了。

“是啊，模塊一般指的是一個(gè)獨(dú)立的單元， 它精確地聲明了對(duì)外的接口和依賴。 你們想想，人類在開(kāi)發(fā)中基本上都是把jar文件作為一個(gè)個(gè)的‘模塊’， 每個(gè)jar文件中包含了一些package , 但是 jar 文件本質(zhì)上還是一堆.class文件的壓縮而已。”

“那該怎么辦?”　用戶系統(tǒng)好奇心被激發(fā)了，它特別想做package的權(quán)限控制。

“最簡(jiǎn)單的辦法，可以在jar包中添加一個(gè)聲明性的文件， 這個(gè)文件定義模塊名，它對(duì)外提供的接口，和依賴， 像這樣：”

用戶系統(tǒng)很激動(dòng)， 這簡(jiǎn)直就是為了他量身定做的： “嗯，這很容易理解， 這個(gè)jar 的模塊名叫做com.foo.db, 依賴另外一個(gè)模塊 java.sql , 這個(gè)export 就是說(shuō)別人只能訪問(wèn)com.foo.db.api這個(gè)package下面的類， 像com.foo.db.impl 就不能訪問(wèn)了，對(duì)吧?”

com.foo.db.jar 文件的內(nèi)容如下：

module-def.xml 
com.foo.db.api.XXXX.class 
com.foo.db.api.XXXX.class 
...... 
com.foo.db.impl.XXXX.class 
com.foo.db.impl.XXXX.class 
...... 

JDK 贊許地說(shuō)： “沒(méi)錯(cuò)， 這就是所謂粗粒度的模塊， 原來(lái)的java class 也可以稱為一個(gè)模塊，但是粒度太細(xì)了， 現(xiàn)在我們把一組類封裝到一個(gè)jar 文件中，再加一個(gè)聲明文件， 就變成了一個(gè)粗粒度模塊。當(dāng)然你肯定能想到，我自己也得做增強(qiáng)嘍， 必須得能識(shí)別模塊定義，并且正確的設(shè)置訪問(wèn)權(quán)限。”

用戶系統(tǒng)說(shuō)： “哎呀， 我其實(shí)最討厭又臭又長(zhǎng)的xml 了， 能不能用java 描述呢，就叫做module-info.java吧”

JDK笑了： “看來(lái)你小子想得挺深的。 我也喜歡這樣清爽的表達(dá)， 只不過(guò)得把java 語(yǔ)法也增強(qiáng)了。增加像module , requries, exports這樣的關(guān)鍵字才行。”

現(xiàn)在： com.foo.db.jar 文件的內(nèi)容如下：

module-info.class 
com.foo.db.api.XXXX 
com.foo.db.api.XXXX 
...... 
com.foo.db.impl.XXXX 
com.foo.db.impl.XXXX 
...... 

3 JDK自身的革命

開(kāi)發(fā)物聯(lián)網(wǎng)的小伙子問(wèn)道： “JDK先生， 你自己是不是也要搞成模塊化啊 ， 這樣我就可以裁剪出我使用的模塊了。”

“是啊， 你們上層要是模塊化了， 我肯定也得這么搞，并且我還得先搞出來(lái)， 這樣你們好使用啊。這對(duì)我來(lái)說(shuō)，是一場(chǎng)巨大的革命啊， 我得把我成千上萬(wàn)的類給捋一捋，形成層次分明，隔離良好的模塊， 我現(xiàn)在才總結(jié)了一部分： java.desktop , java.xml, java.sql , java.naming, java.logging, java.scripting......”

訂單系統(tǒng)打斷說(shuō)： "慢著， 難道讓我在每個(gè)模塊中都導(dǎo)入所有的JDK的基本模塊嗎? 這不把人給累死?"

JDK 說(shuō)： “不不， 這個(gè)問(wèn)題我也考慮過(guò)了，其實(shí)可以引入一個(gè)隱式的依賴嘛， 我把JDK中最重要的核心模塊組織起來(lái)，形成一個(gè)java.base 模塊，其他模塊都隱式的依賴它就行了， 就像你的java類不用extend Object 一樣， JDK會(huì)自動(dòng)給你加上。”

4 遷移

用戶系統(tǒng)說(shuō)： “ 模塊化的想法很不錯(cuò)， 解決了我的問(wèn)題。 可是現(xiàn)有的大部分程序和jar包都沒(méi)有實(shí)現(xiàn)模塊化， 單單自己實(shí)現(xiàn)模塊化有什么用， 你去require 誰(shuí)? 你export出去的接口被誰(shuí)用? ”

大家都向用戶系統(tǒng)投來(lái)了佩服的目光， 這是個(gè)非常現(xiàn)實(shí)的問(wèn)題。

模塊化僅僅有JDK的改變還不夠， 除非大家都用起來(lái)，要不然還是無(wú)法實(shí)施。

log4j 跳出說(shuō)： “是啊是啊， 你們都遷移成模塊了， 我一直沒(méi)改，該怎么辦?”

JDK說(shuō)： “ log4j 你不用擔(dān)心， 肯定得有一種讓大家慢慢遷移到‘模塊’的路徑才行， 就說(shuō)你吧， 還沒(méi)有模塊化，但是用戶系統(tǒng)想擁抱模塊化， 他要require你，該怎么辦?”

“也許我可以臨時(shí)的給他們起個(gè)名字，例如log4j-module , 可是我的模塊怎么才能知道這個(gè)'臨時(shí)模塊'的存在呢?” 用戶系統(tǒng)說(shuō)

“想想classpath , 我們可以搞個(gè)modulepath, 只要加入到這個(gè)modulepath的jar文件，例如log4j.jar , 就自動(dòng)認(rèn)為這是一個(gè)module (雖然他沒(méi)有module-info.java聲明) ， 這樣你就可以requrie log4j 來(lái)使用它了。”

"妙啊，這可以讓大家慢慢的遷移， 我可以先把我的應(yīng)用轉(zhuǎn)化為模塊 , 如果哪個(gè)類庫(kù)還沒(méi)擁抱模塊化， 我就把它放到modulepath中，讓它自動(dòng)成為一個(gè)模塊， 這樣我就可以require了!"

用戶系統(tǒng)對(duì)JDK的方法非常佩服。

“別高興的太早” JDK說(shuō)， “一個(gè)類庫(kù)一旦成為自動(dòng)的模快， 那它就能訪問(wèn)所有的模塊，因?yàn)槲覀儾恢浪降滓蕾囌l(shuí)， 為了能讓大家遷移到模塊化，這也算是一個(gè)代價(jià)吧。 ”

“對(duì)了，要是只有JDK實(shí)現(xiàn)了模塊化， 但是我們上層的應(yīng)用還沒(méi)有開(kāi)始遷移， 能在新的JDK上運(yùn)行嗎? ” 訂單系統(tǒng)擔(dān)憂的問(wèn)道。

“那必須得運(yùn)行，不是自夸，我比較牛的一點(diǎn)就是向后兼容性， 早期的代碼甚至不用修改就可以在***的JRE上運(yùn)行， 新的特性可不能破壞這種兼容性!”

“那該怎么搞? ”

“很簡(jiǎn)單， 我會(huì)把所有這些沒(méi)有遷移的類庫(kù)都放置到一個(gè)叫做unnamed模塊當(dāng)中， 這樣概念上就統(tǒng)一了。 ”

“不錯(cuò)不錯(cuò)， 聽(tīng)起來(lái)可行” 大家紛紛表示贊成 “要不試一試?”

“心急吃不了熱豆腐， 我今天召集大家來(lái)也是把主要的想法給大家分享下， 說(shuō)起來(lái)簡(jiǎn)單， 里邊有很多細(xì)節(jié)我得好好想想才行， 大家耐心地等待下一個(gè)版本的發(fā)行吧!”

后記： 本文介紹的就是Java9的新特性： 模塊化的一些概念， 還有很多其他的細(xì)節(jié)，感興趣的同學(xué)可以點(diǎn)擊閱讀原文去openjdk 的網(wǎng)站上去看看 。

【本文為51CTO專欄作者“劉欣”的原創(chuàng)稿件，轉(zhuǎn)載請(qǐng)通過(guò)作者微信公眾號(hào)coderising獲取授權(quán)】

戳這里，看該作者更多好文