Java 9特性

　　Oracle已經公佈，Java9首個增強計劃集（眾所周知的JEPs），已經確定會在2016年早些時候釋出。

　　三個新的API已經公佈：

　　Process API在更新後能夠與作業系統中非JAVA相關的程式互動，目前使用的API存在諸多限制，這迫使開發人員經常求助於原生程式碼。這個API存在的主要風險是作業系統的異構性，尤其是Windows。該API的設計需要適應在不同的作業系統上的小型裝置的部署工作，它還應該考慮多個Java虛擬機器執行在同一個作業系統程式的環境。這些考量將帶來一個更為抽象的API，這會增加設計的工作量。

　　新的HTTP客戶端，引入了對HTTP/2的支援。

　　現有API的問題及實現：

• 基於URLConnection的API是考慮到多種協議而設計的，其中很多都已經被廢棄了(ftp, gopher等)
• 早先的HTTP 1.1過於抽象
• 難以使用（許多行為都沒有文件化）
• 只能以阻塞模式工作（每個請求/響應對應一個執行緒）
• 非常難以維護

　　Https 2.0支援依賴於TLS ALPN (Application Layer Negotiation Extension)，目前JDK中並不支援，Http 2.0規範本身還處於網際網路草案的形式，但在2014年它有望成為一個正式草案。

　　新的輕量級JSON API：它提供了一個輕量級的API用來處理和生成JSON文件以及資料流，後者是基於已經標準化的JSON支援，它是JSR 353的一部分。

　　還有三個JVM和效能相關的特性公佈：

　　改進競爭鎖，旨在改進當執行緒競爭訪問物件時的效能。改進競爭鎖對現實世界中的應用程式大有裨益，尤其是針對工業基準，如Volano和DaCapo。

　　這項工程將在以下與競爭Java監視器相關的領域，探索效能改進：

• 欄位重排序(Field reordering)和快取線對齊(cache line alignment)
• 加速PlatformEvent::unpark()
• 快速的Java監視器操作進入操作
• 快速的Java監視器退出操作
• 快速的Java監視器notify/notifyAll操作
• 自適應的spin改進以及SPARC上的SpinPause

　　分割JIT編譯器的程式碼快取（在大型應用程式上獲得更好的JIT效能）。將程式碼快取分解為獨立的段，每個段都包含特定形式的編譯程式碼，目的是為了改善效能，並支援未來擴充套件。

　　編譯程式碼的組織和維護會對效能造成巨大影響，如果程式碼快取走錯了方向，若干方面的效能退化例項將會獲悉。在引入多層編譯後，程式碼快取的地位變得極其重要，因為編譯程式碼的數量比起不使用多層編譯，會有2-4倍的增長。多層編譯也引入了一個新的編譯程式碼型別：instrumented編譯程式碼 (異型程式碼)。異形程式碼具備與非異形程式碼不同的屬性，其中一個重要區別是，異形程式碼有一個預定義的限制性生命週期，與此相反，非異形程式碼永遠都會保留在程式碼快取中。

　　現存的程式碼快取是針對單一程式碼優化的，即只有一種形式的編譯程式碼。程式碼快取被組織為一個獨立的堆資料結構，位於一個連續的記憶體塊頭部。因此，具有預定義的限制性生命週期的異形程式碼將與非異形程式碼混合，並永久保留在程式碼快取中，這會帶來不用的效能和設計問題。比如說，sweeper方法在掃描時將被迫掃描整個程式碼快取，即使其中一些實體從未更新，或存在非方法的程式碼。

　　“智慧的”Java編譯器的深入開發，稱之為sjavac，它支援並行和共享編譯，還包含一些其他特性。

　　由於存在各類關於穩定性和可移植性的問題，sjavac在預設情況下並沒有在JDK構建指令碼中使用，這項JEP的首個目標是解決這些問題，這牽扯到必須確保工具能始終在所有的軟硬體配置上產生可靠的結果。

　　總體目標是要改善sjavac的質量，使其成為一個通用的javac封裝，有能力編譯各種大型Java專案。

　　後續專案將繼續探索如何在JDK工具鏈中將sjavac分離出來，如果可以的話。sjavac可能會成為一個獨立支援的工具，或是與javac整合的非獨立工具，或是其他。

　　最後，一個誘人的特性已經在JEP 201中得到了承諾：模組化原始碼。這其實就是曾經我們熟知的模組化解決方案“Jigsaw專案”（最初目標是Java 8的一部分）。

　　Jigsaw專案旨在為Java SE平臺設計和實現一套標準化的模組系統，並應用於自身平臺中，繼而投入到JDK中。其最初的目標是使平臺實現更容易擴充套件到小型裝置上，改善安全性和可維護性，改善應用程式效能，並提供給開發人員在面對大型應用時一種更好的工具。

　　這項JEP是Jigsaw專案的第一階段的一部分，接下來JEP會將JRE和JDK的映象模組化，之後再引入一個模組系統。

　　在早期對原始碼進行重新組織的動機是：

1. 讓JDK開發人員有機會熟悉系統的模組化結構。
2. 通過在構建中強制模組邊界，繼續推進結構，這甚至會發生在引入模組系統之前。
3. 對Jigsaw專案進行深入開發，而不是總是“慢吞吞地”將現有的非模組化程式碼轉化為模組化程式碼。

　　原文連結： devamanthrills 翻譯：ImportNew