這期內(nèi)容當(dāng)中小編將會給大家?guī)碛嘘P(guān)怎么在java9中區(qū)分opens與exports，文章內(nèi)容豐富且以專業(yè)的角度為大家分析和敘述，閱讀完這篇文章希望大家可以有所收獲。

目前創(chuàng)新互聯(lián)已為上千的企業(yè)提供了網(wǎng)站建設(shè)、域名、虛擬主機、網(wǎng)站托管、服務(wù)器托管、企業(yè)網(wǎng)站設(shè)計、安吉網(wǎng)站維護等服務(wù)，公司將堅持客戶導(dǎo)向、應(yīng)用為本的策略，正道將秉承"和諧、參與、激情"的文化，與客戶和合作伙伴齊心協(xié)力一起成長，共同發(fā)展。

遷移種類

1. 代碼不模塊化，先遷移到j(luò)dk9上，好利用jdk9的api

2. 代碼同時也模塊化遷移

幾點注意事項

不可讀類

比如sun.security.x509，在java9中歸到j(luò)ava.base模塊中，但是該模塊沒有export該package

可以通過運行的時候添加--add-exports java.base/sun.security.x509=ALL-UNNAMED來修改exports設(shè)定

內(nèi)部類

比如sun.misc.Unsafe，原本只想讓oracle jdk team來使用，不過由于這些類應(yīng)用太廣泛了，為了向后兼容，java9做了妥協(xié)，只是將這些類歸到了jdk.unsupported模塊，并沒有限定其可讀性。

? ~ java -d jdk.unsupported
jdk.unsupported@9
exports com.sun.nio.file
exports sun.misc
exports sun.reflect
requires java.base mandated
opens sun.misc
opens sun.reflect

刪除的類

java9刪除了sun.misc.BASE64Encoder，這種情況只能改用其他api，比如java.util.Base64

classpath vs module-path

java9引入了模塊系統(tǒng)，同時自身的jdk也模塊化了，引入了module-path，來屏蔽classpath，也就是說在java9優(yōu)先使用module-path，畢竟jdk本身都模塊化了，應(yīng)用本身沒有模塊化的話，java9通過unnamed modules及automatic modules機制來隱式模塊化，當(dāng)然classpath在java9上還能繼續(xù)使用，比如配合module-path使用等。

沒有模塊化的jar在classpath會被歸到unnamed modules；在module-path則會被自動創(chuàng)建為automatic modules(一個automatic modules會聲明transitive依賴所有named和unnamed module，然后導(dǎo)出自身的package)

一個包名不能在多個模塊中出現(xiàn)(split packages)

因為模塊中可以exports指定包給其他模塊，如果多個模塊exports同樣的包名會造成混亂，特別若有其他類庫同時requires這兩個模塊，就不知道該引用那個模塊的了。

傳遞依賴

如果一個模塊的接口參數(shù)或返回類型使用了其他模塊的類，則建議requires transitive它依賴的模塊

小心循環(huán)依賴

在設(shè)計模塊的時候，要盡可能考慮到是否會有循環(huán)依賴的問題，如果有則需要重新設(shè)計

使用services來實現(xiàn)optional依賴

services特別適合用來解耦調(diào)用方與實現(xiàn)類依賴的問題，如果接口有多種實現(xiàn)類，調(diào)用方不必要requires所有的實現(xiàn)類，只需要requires接口即可，使用services類型來加載實現(xiàn)類的實例。通過在module-path去動態(tài)添加實現(xiàn)模塊實現(xiàn)解耦。

模塊版本管理

module-info.java不支持聲明版本號，但是創(chuàng)建jar包的時候，可以通過--module-version設(shè)置。不過模塊系統(tǒng)查找模塊的時候還是使用模塊名來查找(如果module-path里頭有多個重名模塊，則模塊系統(tǒng)知會使用找到的第一個，自動忽略后續(xù)的同名模塊)，版本依賴問題不在模塊系統(tǒng)解決范疇內(nèi)，交由maven之類的依賴管理工具去管理。

模塊資源訪問

模塊化之后資源文件也收到保護，只能由該模塊去訪問本模塊自身的資源文件，如果需要跨模塊訪問，也必須借助ModuleLayer找到目標(biāo)模塊，再調(diào)用目標(biāo)模塊去加載該模塊的資源文件。

反射的使用

這里涉及到deep reflection問題，所謂的deep reflection就是通過反射去調(diào)用一個class的非public元素。module-info.java的exports聲明package只是允許該package直接所屬的類允許訪問其public元素，并不允許反射調(diào)用非public元素。

反射在模塊系統(tǒng)里頭需要特殊聲明才允許使用(使用opens聲明允許deep reflection)，這樣就導(dǎo)致很多使用反射的類庫諸如spring，需要額外配置才能遷移到j(luò)ava9。解決方案有兩個：一個是opens package包名給需要反射的模塊，比如spring.beans等；一個就是直接opens整個模塊。

默認(rèn)--illegal-access=permit，同時該設(shè)置只適用于java9之前的package在java9被不允許訪問，不適用于java9中新的不允許訪問的package.(建議遷移到模塊化系統(tǒng)時設(shè)置為deny)

不過就是在模塊系統(tǒng)中包名不一樣就屬于不同的包，沒有繼承關(guān)系，比如com.service.func1與com.service.func2這兩個是不同的包，你不能只opens com.service，必須分別指定這樣就導(dǎo)致需要open的的package比較多。因此open整個module可能更省事一點，但也屬于比較粗暴的做法。

上面的做法是在原來module-info.java里頭去做修改，另外一種是在執(zhí)行java或javac的時候通過指定的命令來修改原來的關(guān)系。比如

java ... --add-opens source-module/source-package=target-module

如果需要導(dǎo)出給unnamed modules，則target-module為ALL-UNNAMED

當(dāng)然如果是新的系統(tǒng)，那就不建議使用反射了，可以使用MethodHandles及VarHandles。

常見問題和措施

ClassNotFoundException/NoClassDefFoundError

比如javax.xml.bind.JAXBException，JAXB已經(jīng)歸入到j(luò)ava.xml.bind模塊，在java命名后面添加

--add-modules java.xml.bind

如果圖省事，把$JAVA_HOME及所有第三方類庫添加到module-path，然后來個

--add-modules ALL-MODULE-PATH

illegal reflective access by xxx to method java.lang.ClassLoader.defineClass

反射原因引起，由于舊系統(tǒng)沒有module-info，因此在java命名添加參數(shù)加以修改

--add-opens java.base/java.lang=ALL-UNNAMED

確定依賴的模塊

通過IDE或者jdeps分析

jdeps --class-path 'classes/lib/*' -recursive -summary app.jar

jdeps只是靜態(tài)代碼分析，如果有使用反射用的類jdeps分析不出來，需要自己手工requires，如果dependency是optional的，可以requires static

對模塊單元測試的可讀性問題

如果單元測試時單獨模塊的話，可以在運行時通過--add-exports或--add-opens來授予單元測試模塊對目標(biāo)模塊的可讀性及反射能力。另外由于split packages問題，單元測試類的包名不能跟目標(biāo)模塊包名重復(fù)。原來maven工程那種test

上述就是小編為大家分享的怎么在java9中區(qū)分opens與exports了，如果剛好有類似的疑惑，不妨參照上述分析進行理解。如果想知道更多相關(guān)知識，歡迎關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道。