長期支援版本Java 11釋出，更新TLS 1.3並加入高效能垃圾回收器
甲骨文提醒開發者，TLS 1.3使用半關閉政策，與TLS 1.2和先前版本都不同，因此原本採用雙工關閉政策的應用程式，升級可能遇到相容性問題。
按讚加入iThome粉絲團
文/李建興 | 2018-09-27發表
Java 10在3月釋出時便預告，Java 11將會在9月時到來，並且為長期支援版本，而今甲骨文依照預告釋出Java 11，成為從去年宣布每六個月發布新版本計畫下的第一個長期支援版本。這個版本重點放在增強開發人員生產力及對先進加密和網際網路標準的支援，包括TLS 1.3和HTTP/2。
全球Java開發人員和甲骨文的工程師，透過OpenJDK社群以及JCP的努力下，釋出了Java SE 11（JDK 11），從Java SE 8以來，社群增加了超過100個新功能強化，共同發布了JDK 9、10和這次的第11版。
最近傳輸層安全性協定TLS 1.3標準通過，Java作為企業最愛用開發語言，也正式開始支援TLS 1.3，但新舊版本升級有特別需要注意的地方，官方提到，TLS 1.3使用半關閉政策，而TLS 1.2和先前版本則使用雙工關閉政策，因此對於原本依賴雙工關閉政策的應用程式，升級到TLS 1.3的時候可能存在相容性問題。TLS 1.3不支援DSA簽章演算法，當伺服器配置僅只使用DSA憑證，則無法升級到TLS 1.3。
TLS 1.3支援的加密套件與TLS 1.2和更早版本都不同，因此當應用程式硬編碼加密套件不再提供支援，則可能無法在不修改程式碼的情況下直接使用TLS 1.3。另外，TLS 1.3對話恢復和密鑰更新行為都和TLS 1.2等早前版本不同，雖然這些改變對相容性影響不大，但是當應用程式依賴TLS協定的交握細節，則可能會存在風險。
Java 11引入了基於巢的存取控制（Nest-Based Access Control ），這個存取控制上下文（Access Control Context）和Java中既有的巢狀型別概念一致。在Java SE 11中，Java虛擬機器將類別和介面安排到一個新的存取控制上下文中稱為巢，巢允許在邏輯上為相同程式碼實體部分的類別和介面，但是卻被編譯到不同類別檔案，也能夠存取彼此的私有成員，而不需要編譯器插入可存取擴展方法。
這次更新加入了一個實驗性的功能，稱為可擴展的低延遲垃圾回收器（Scalable Low-Latency Garbage Collector，ZGC），目的在使暫停時間不超過10ms，且暫停時間不隨著堆積或是即時配置大小而改變，並有能力處理數百MB到數TB堆積的能力。由於ZGC的核心是並行垃圾回收器，而這代表著當Java執行緒還正在運作的時候，所有諸如參照處理或是字串表清除等繁重的工作，都已經能夠同時處理完成，而這極大程度降低了垃圾回收工作對於應用程式回應時間的負面影響。
其他重要的更新還有動態類別檔案常量（Dynamic Class-file Constants），能降低創建可實體化類別檔案常量新形式時的成本。此外還有Flight Recorder，這是一個用於Java應用程式和HotSpot JVM故障排除的低成本的資料收集框架。
甲骨文對Java 11進行了不少更新和修正，更詳細的資訊可以參照Java 11釋出說明文件。
https://www.ithome.com.tw/news/126133