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)

加速Platform::unpark(cache line alignment)

加速Platform::unpark()

快速的Java監視器操作進入操作

快速的Java監視器退出操作

快速的Java監視器notify/notifyAll操作

自適應的spin改進以及SPARC上的SpinPause

　　JIT編譯器的快取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的鏡像模組化，之後再引入一個模組系統。

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

讓JDK開發人員有機會熟悉系統的模組化結構。

透過在建造中強制模組邊界，繼續推進結構，這甚至會發生在引入模組系統之前。

對Jigsaw專案進行深入開發，而不是總是「慢吞吞地」將現有的非模組化程式碼轉換為模組化程式碼。