1. Jigsaw 項目;模塊化源碼
Jigsaw項目是爲了模塊化Java代碼、將JRE分紅可相互協做的組件,這也是Java 9 衆多特點種的一個。JEP是邁向Jigsaw四步中的第一步,它不會改變JRE和JDK的真實結構。JEP是爲了模塊化JDK源代碼,讓編譯系統可以模塊編譯並在構建時檢查模塊邊界。這個項目本來是隨Java 8發佈的,但因爲推遲,因此將把它加到Java 9.
一旦它完成,它可能容許根據一個項目需求自定義組件從而減小rt.jar的大小。在JDK 7 和JDK 8的rt.jar包中有大約20,000個類,但有不少類在一些特定的環境裏面並無被用到(即便在Java 8的緊湊分佈特性中已經包含了一部分解決方法也存在着類冗餘)。這麼作是爲了能讓Java可以容易應用到小型計算設備(好比網絡設備)中,提升它的安全和性能,同時也能讓開發者更容易構建和維護這些類庫。
2. 簡化進程API
截止到目前,Java控制與管理系統進程的能力是有限的。舉個例子,如今爲了簡便獲取你程序的進程PID,你要麼調用本地程序要麼要本身使用一些變通方案。更多的是,每一個(系統)平臺須要有一個不一樣實現來確保你能得到正確的結果。
指望代碼能獲取Linux PIDS,如今是以下方式:
public static void main(String[] args) throws Exception
{
Process proc = Runtime.getRuntime().exec(new String[]{ "/bin/sh", "-c", "echo $PPID" });
if (proc.waitFor() == 0)
{
InputStream in = proc.getInputStream();
int available = in.available();
byte[] outputBytes = new byte[available];
in.read(outputBytes);
String pid = new String(outputBytes);
System.out.println("Your pid is " + pid);
}
}
在Java 9中,能夠變換成以下方式(支持全部的操做系統):
System.out.println("Your pid is " + Process.getCurrentPid());
3. 輕量級 JSON API
目前有多種處理JSON的Java工具,但JSON API 獨到之處在於JSON API將做爲Java語言的一部分,輕量而且運用Java 8的新特性。它將放在java.util包裏一塊兒發佈(但在JSR 353裏面的JSON是用第三方包或者其餘的方法處理的).
4. 錢和貨幣的API
在Java 8引進了日期和時間的API以後, Java 9引入了新的貨幣API, 用以表示貨幣, 支持幣種之間的轉換和各類複雜運算. 關於這個項目的具體狀況, 請訪問https://github.com/JavaMoney,裏面已經給出了使用說明和示例, 如下是幾個重要的例子:
//新的類型: Money & FastMoney
Money amt1 = Money.of(10.1234556123456789, "USD"); // Money is a BigDecimal
FastMoney amt2 = FastMoney.of(123456789, "USD"); // FastMoney is up to 5 decimal places
Money total = amt1.add(amt2);
// 錢表達成各國貨幣的方法:
MonetaryAmountFormat germanFormat = MonetaryFormats.getAmountFormat(
Locale.GERMANY);
System.out.println(germanFormat.format(monetaryAmount)); // 1.202,12 USD
5. 改善鎖爭用機制
鎖爭用是限制許多Java多線程應用性能的瓶頸. 新的機制在改善Java對象監視器的性能方面已經獲得了多種基準(benchmark)的驗證, 其中包括Volano. 測試中通信服務器開放了海量的進程來鏈接客戶端, 其中有不少鏈接都申請同一個資源, 以此模擬重負荷平常應用.
經過諸如此類的壓力測試咱們能夠估算JVM的極限吞吐量(每秒的消息數量). JEP在22種不一樣的測試中都獲得了出色的成績, 新的機制若是能在Java 9中獲得應用的話, 應用程序的性能將會大大提高.
6. 代碼分段緩存
Java 9的另外一個性能提高來自於JIT(Just-in-time)編譯器. 當某段代碼被大量重複執行的時候, 虛擬機會把這段代碼編譯成機器碼(native code)並儲存在代碼緩存裏面, 進而經過訪問緩存中不一樣分段的代碼來提高編譯器的效率.
和原來的單一緩存區域不一樣的是, 新的代碼緩存根據代碼自身的生命週期而分爲三種:
- 永駐代碼(JVM 內置 / 非方法代碼)
- 短時間代碼(僅在某些條件下適用的配置性(profiled)代碼)
- 長期代碼(非配置性代碼)
緩存分段會在各個方面提高程序的性能, 好比作垃圾回收掃描的時候能夠直接跳過非方法代碼(永駐代碼), 從而提高效率.
7. 智能Java編譯, 第二階段
智能Java編譯工具sjavac的第一階段開始於JEP 139這個項目, 用於在多核處理器上提高JDK的編譯速度. 如今這個項目已經進入第二階段(JEP 199), 目的是改進sjavac並讓其成爲取代目前JDK編譯工具javac的Java默認的通用編譯工具.
8. HTTP 2.0客戶端
HTTP 2.0標準雖然還沒正式發佈, 可是已經進入了最終審查階段, 預計能夠在Java 9發佈以前審查完畢. JEP 110將會從新定義並實現一個全新的Java HTTP客戶端, 用來取代如今的HttpURLConnection, 同時也會實現HTTP 2.0和網絡接口(原文websockets). 它如今還沒被JEP正式承認但咱們但願在Java 9中包含這一項目的內容.
官方的HTTP 2.0 RFC(Request for Comments, 官方技術討論/會議記錄等等的一系列文檔記錄)預訂於2015年2月發佈, 它是基於Google發佈的SPDY(Speedy, 快速的)協議. 基於SPDY協議的網絡相對於基於HTTP 1.1協議的網絡有11.81%到47.7%之間的顯著提速, 如今已經有瀏覽器實現了這個協議.
9. Kulla計劃: Java的REPL實現
這個取名爲Kulla的項目最近宣佈將於2015年4月整合測試, 雖然已經不太有但願能遇上Java 9的發佈, 但若是進度快的話或許恰好能遇上. 如今Java並無來自官方的REPL(Read-Eval-Print-Loop)方式, 也就是說如今若是你想要跑幾行Java代碼作一個快速的測試, 你仍然須要把這幾行代碼封裝在項目或者方法裏面. 雖然在一些流行的IDE裏面有Java REPL工具, 但它們並無官方支持, 而Kulla項目或許就能成爲Java官方發佈的REPL解決方案.