Java 9正式發(fā)布，新特性解讀

責(zé)任編輯：editor004 作者：楊曉峰 |來源：企業(yè)網(wǎng)D1Net 2017-09-22 10:11:22 本文摘自：InfoQ

　編輯｜徐川、小智

在歷經(jīng)多次跳票之后，Java 9 終于在千呼萬喚中正式發(fā)布。從這個版本開始，Java 將每半年發(fā)布一個版本。作為霸占編程語言排行榜鰲頭多年的老牌語言，Java 9 中有哪些不得不說的新特性？Java 語言的未來又將如何？

針對 Java 9 新特性的介紹已經(jīng)非常多了，我這里不想再做一個百科全書一樣的列表，希望從不同角度簡要點評部分特性。

Jigsaw

首先，談到 Java 9 大家往往第一個想到的就是 Jigsaw 項目，這是一個雄心勃勃的項目。

大家知道，Java 已經(jīng)發(fā)展超過 20 年（95 年最初發(fā)布），Java 和相關(guān)生態(tài)在不斷豐富的同時也越來越暴露出一些問題，比如 Java 運行環(huán)境的膨脹和臃腫，各種類庫和工具在提供強大功能的同時，也越來越復(fù)雜，不同版本的類庫交叉依賴導(dǎo)致 Jar Hell 等讓人頭疼的問題，這些都阻礙了 Java 開發(fā)和運行效率的提升。

但是由于兼容性等各方面的掣肘，對 Java 進行大刀闊斧的革新越來越困難，Jigsaw 從 Java 7 階段就開始籌備，Java 8 階段進行了大量工作，終于在 Java 9 里落地，有種千呼萬喚始出來的意味。

Jigsaw 項目的目標(biāo)是改進 Java SE 平臺，使其可以適應(yīng)不同大小的計算設(shè)備；改進其安全性，可維護性，提高性能；簡化各種類庫和大型應(yīng)用的開發(fā)和維護。

這個項目的工作量和難度大大超出了初始規(guī)劃。JSR 376 Java 平臺模塊化系統(tǒng)（JPMS, Java Platform Module System）作為 Jigsaw 項目的核心, 其主體部分被分解成 6 個 JEP(JDK Enhancement Proposals)

200: The Modular JDK

201: Modular Source Code

220: Modular Run-Time Images

260: Encapsulate Most Internal APIs

261: Module System

282: jlink: The Java Linker

可以看到這是一個龐大的系統(tǒng)工程，Java 的方方面面，包括 JDK 編譯工具，運行時，Java 公共 API 和私有代碼等等，完全是一個整體性的改變。

隨著 Java 平臺模塊化系統(tǒng)的落地，開發(fā)人員無需再為不斷膨脹的 Java 平臺苦惱，例如，您可以使用 jlink 工具，根據(jù)需要定制運行時環(huán)境。這對于擁有大量鏡像的容器應(yīng)用場景或復(fù)雜依賴關(guān)系的大型應(yīng)用等，都具有非常重要的意義。

從軟件開發(fā)實踐的角度，Java 語言層面提供對模塊的支持，可以鼓勵（當(dāng)然在某種程度上也可以看作強制）更加規(guī)范的開發(fā)實踐，利用業(yè)界在開發(fā)領(lǐng)域幾十年的經(jīng)驗、教訓(xùn)總結(jié)出的最佳實踐，促進 Java 生態(tài)的健康發(fā)展。比如，更加完善的隱藏實現(xiàn)細節(jié)，這不僅可以促進面向接口、約定的編程，也可以避免可能的安全風(fēng)險等。

不過，換個角度來說，天下沒有免費的午餐，由于 JPMS 是語言平臺層面的支持，它并不是完全透明的，也就是說不管用戶是否真的需要或從中收益，都會或多或少的受其影響。

對此，我們可以從 JPMS 評審中針對類似深度反射限制之類的激烈爭吵中，深刻體會到。比如，針對反射訪問控制，最終 Java 9 開發(fā)團隊，采取了相對折中的辦法，在反射領(lǐng)域默認保持 Java 8 的默認行為。Java 9 在兼容性方面，相比于過往的版本，采取了更大的容忍度。

不過，Java 9 的相當(dāng)一部分特性仍然是對用戶透明的。只要升級到 Java 9，不需要或者很少需要用戶參與動作就能獲益。比如，更加緊湊的字符串實現(xiàn)；改進的競爭鎖機制；改進安全應(yīng)用性能；利用特定 CPU 指令優(yōu)化 GHASH 和 RSA 等等，這些都是開箱即用、觸手可得的改進。

Java 9 值得關(guān)注的新特性

對于部分開發(fā)者來說，探究 Java 內(nèi)部 API 或者平臺底層能力是一件非常酷的事情，但這往往并不是非常容易，比如部分能力可能并沒有在歷史版本的公共 API 中暴露出來（比如 Unsafe 相關(guān)），或者需要特定領(lǐng)域的知識。在 Java 9 中，不要錯過 JEP 193: Variable Handles 和 JEP 274: Enhanced Method Handles，JEP 259: Stack-Walking API，JEP 285: Spin-Wait Hints 等特性。

另外，Java 9 中還有很多承上啟下的特性，為未來創(chuàng)新打下基礎(chǔ)或者整合、規(guī)范現(xiàn)有碎片化的功能，我會介紹一些有代表性的新特性。

在 Java 虛擬機領(lǐng)域，JEP 271: Unified GC Logging 和 JEP 158：Unified JVM Logging，對各種 JVM 日志進行了統(tǒng)一，大家終于不用為各種碎片化的日志選項苦惱了。

Oracle 一直在努力提高 Java 啟動和運行時性能，希望其能夠在更廣泛的場景達到或接近本地語言的性能。但是，直到今天，談到 Java，很多 C/C++ 開發(fā)者還是會不屑地評價為啟動慢，吃內(nèi)存。

簡單說，這主要是因為 Java 編譯產(chǎn)生的類文件是 Java 虛擬機可以理解的二進制代碼，而不是真正的可執(zhí)行的本地代碼，需要 Java 虛擬機進行解釋和編譯，這帶來了額外的開銷。

JIT（Just-in-time）編譯器可以在運行時將熱點編譯成本地代碼，但是實際應(yīng)用可能非常龐大，大型 Java 應(yīng)用的預(yù)熱往往非常耗時，而且非熱點代碼可能根本沒有機會被 JIT 編譯。

在 JDK 9 中， AOT（JEP 295: Ahead-of-Time Compilation）作為實驗特性被引入進來，開發(fā)者可以利用新的 jaotc 工具將重點代碼轉(zhuǎn)換成類似類庫一樣的文件，這樣會大大降低啟動開銷。

另外 JVMCI （JEP 243: Java-Level JVM Compiler Interface）等特性，對于整個編程語言的發(fā)展，可能都具有非常重要的意義，雖然未必引起了廣泛關(guān)注。目前 Graal Core API 已經(jīng)被集成進入 Java 9，雖然還只是初始一小步，但是完全用 Java 語言來實現(xiàn)的可靠的、高性能的動態(tài)編譯器，似乎不再是遙不可及，這是 Java 虛擬機開發(fā)工程師的福音。

與此同時，隨著 Truffle 框架和 Substrate VM 的發(fā)展，已經(jīng)讓個別信心滿滿的工程師高呼“One VM to Rule Them All!”，也許就在不遠的將來 Ploygot 以一種另類的方式成為現(xiàn)實。

談?wù)?Java 的未來

前面簡短地談了談 Java 9 中的一些令人激動的特性，Java 9 在取得這些進步的同時，那么在其的研發(fā)過程中有哪些教訓(xùn)，當(dāng)前和未來遇到了那些挑戰(zhàn)呢？

首先，就是如何更加快速、敏捷地進行創(chuàng)新。在 Java 9 的開發(fā)過程中, 非常突出的一點就是，由于 Jigsaw 項目的延期，導(dǎo)致 Java 9 的發(fā)布一再推遲，這帶來了很多負面影響。大批特性已經(jīng)完成多時，卻無法及時被實際應(yīng)用采納，開發(fā)者無法及時地從中獲益，也很難盡早發(fā)現(xiàn)和反饋可能存在的問題或改進。這不禁讓人反思 Java 傳統(tǒng)的研發(fā)模式的局限性。

針對這些情況，Java 首席架構(gòu)師 Mark Reinhold 已經(jīng)發(fā)出倡議，建議從傳統(tǒng)的以特性驅(qū)動的發(fā)布周期，轉(zhuǎn)變?yōu)橐詴r間驅(qū)動的（6 個月為周期）發(fā)布模式，并逐步的將 Oracle JDK 原有商業(yè)特性進行開源，Java Flight Recorder 等殺手級工具和特性，一定會大受開發(fā)者的歡迎。針對企業(yè)客戶的需求，Oracle 將以三年為周期發(fā)布長期支持版本（long term support）。

第二，隨著云計算和 AI 等技術(shù)浪潮，當(dāng)前的計算模式和場景正在發(fā)生翻天覆地的變化，不僅對 Java 的發(fā)展速度提出了更高要求，也深刻影響著 Java 技術(shù)的發(fā)展方向。傳統(tǒng)的大型企業(yè)或互聯(lián)網(wǎng)應(yīng)用，正在被云端，容器化應(yīng)用、模塊化的微服務(wù)甚至是函數(shù)（FaaS， Function-as-a-Service）所替代。

Java 需要在新的計算場景下，改進開發(fā)效率。這話說的有點籠統(tǒng)，我談一些自己的體會，Java 代碼雖然進行了一些類型推斷等改進，更易用的集合 API 等，但仍然給開發(fā)者留下了過于刻板、形式主義的印象，這是一個長期的改進方向，例如，JEP 286: Local-Variable Type Inference；持續(xù)改進并發(fā)計算框架，Java 的并發(fā)特性非常強大和系統(tǒng)，但某種程度上過于復(fù)雜，在今年的 JVMLS 上，阿里巴巴 AJDK 組介紹了利用協(xié)程改進并發(fā)的實踐，這是一個令人眼前一亮的創(chuàng)新；Java 非常需要更加友好的本地代碼支持，相關(guān)的特性有很多好的想法和嘗試，比如 Panama 項目；Value Types 和改進的泛型，有興趣可以參考 Valhalla 項目。

最后，進一步改進啟動和運行性能、優(yōu)化計算資源使用。目前，相當(dāng)一部分的 Java 類庫和虛擬機特性都是針對長時間、大數(shù)據(jù)量、高并發(fā)等復(fù)雜任務(wù)進行的優(yōu)化，但是在部分云計算場景中，比如越來越引起大家關(guān)注的 FaaS 應(yīng)用，短時間、無狀態(tài)的函數(shù)正在成為常見的計算單元。那么在這種場景下，Java 必須進行相應(yīng)的改進和創(chuàng)新，才能保持和強化目前在軟件開發(fā)領(lǐng)域的競爭力。比如，提高 Java 運行時啟動速度，尤其是在容器環(huán)境的初始化表現(xiàn)；保證 CPU 等計算資源調(diào)度能力能夠適應(yīng)容器環(huán)境的新情況，最直接的就是 Java 平臺需要支持基于 cgroup 等技術(shù)的資源管理；針對新場景下的 GC 優(yōu)化；如何提高數(shù)據(jù)密度和計算效率等等。

以上很多方面往往不是孤立的，也不是非常簡單就可以完成的，很多改進都是依賴于相關(guān)語言基礎(chǔ)技術(shù)的進步和突破，Java 的進步需要持之以恒的耐心和持續(xù)的努力與投入。

最后，歡迎大家能夠參與到 OpenJDK 社區(qū)，Java 是大家的，歡迎您向 OpenJDK 提供建議、意見或者直接提交自己的改進，在社區(qū)中聽見越來越多的來自中國的聲音是非常令人高興的事情，讓我們攜手促進 Java 的創(chuàng)新和發(fā)展。