Java開發工具包（JDK）14已進入發佈候選階段，總體功能基本已確定。計劃中的標準Java升級將具有新功能，例如JDK Flight Recorder事件流，模式匹配和開關表達式。
JDK 14計劃在Java設定六個月的發佈節奏之後，於2020年3月17 日正式發佈。針對JDK 14的功能包括：
- JFR事件流 提供一個API，用於持續使用來自流程內和流程外應用程序的JFR數據。JFR是用於收集有關正在運行的Java應用程序的概要分析和診斷數據的工具。事件流建議記錄與非流情況相同的事件集，並且如果可能，開銷小於百分之一。事件流必須與基於磁盤和基於內存的非流記錄共存。在這種情況下，HotSpot VM使用JFR發出500個以上的數據點，而其中的大多數數據僅可通過分析日誌文件來使用，因此很容易激發這種提議。當前，用戶必須開始錄製，停止錄製，將內容轉儲到磁盤，然後解析錄製文件。這對於應用程序概要分析非常有效，但不適用於監視目的。監控使用情況的一個示例是顯示動態更新數據的儀表板。創建記錄會產生開銷，例如將數據從磁盤存儲庫複製到單獨的記錄文件。如果有一種方法可以在不創建新記錄文件的情況下從磁盤存儲庫讀取正在記錄的數據，則可以避免很多開銷。
- 計劃進行的改進 NullPointerExceptions涉及通過準確描述哪個變量爲null來提高JVM生成的異常的可用性。該提案的作者希望爲開發人員和支持人員提供有關程序過早終止的有用信息，並通過更清楚地將動態異常與靜態程序代碼相關聯來提高對程序的理解。一個目標是減少開發人員的困惑和擔憂NullPointerExceptions。
- 非易失性映射的字節緩衝區將添加新的特定於JDK的文件映射模式，該模式允許使用FileChannel API創建MappedByteBuffer引用非易失性內存（NVM）的實例。NVM使程序員可以跨程序運行來構建和更新程序狀態，而不會產生輸入和輸出操作通常需要的大量複製或翻譯成本。這對於交易程序尤其重要。因此，此JDK增強建議的主要目標是確保客戶端可以連貫且有效地從Java程序訪問和更新NVM。第二個目標是使用在class中定義的受限制的JDK內部API來實現此提交行爲Unsafe，因此除其他類外，它可以重用它。MappedByteBuffer可能需要提交給NVM。另一個目標是允許現有API跟蹤在NVM上映射的緩衝區，以進行監視和管理。目標OS / CPU平臺包括Linux / x64和Linux / AArch64。
- 開關表達式通過擴展switch使其可以用作語句或表達式而簡化了編碼 。在JDK 12和JDK 13中都進行預覽之後，開關表達式有望成爲JDK 14的永久功能。開關表達式還爲使用模式匹配做好了準備switch。模式匹配使開發人員可以更簡潔，安全地從對象中有條件地提取組件。
- G1垃圾回收器的NUMA感知內存分配，旨在提高大型計算機上的G1性能。
- 刪除併發標記掃描（CMS）垃圾收集器，該垃圾收集器先前已棄用並計劃刪除。CMS的後繼者包括ZGC和Shenandoah。
- 將ZGC移植到MacOS。到目前爲止，僅Linux才支持它。
- 刪除java.util.jar軟件包中的pack200和unpack200工具以及Pack200 API 。所有這些在Java SE 11中已棄用，目的是將來刪除它們。Pack200是JAR文件的壓縮方案。
- 記錄，它將提供一種緊湊的語法來聲明爲淺層不可變數據的透明持有者的類。該提案指出，聲明淺不可改變的，行爲良好的名義數據集合應該簡單明瞭。
- 一種打包工具，處於開發的孵化階段，用於打包自包含的Java應用程序。該工具將基於JavaFX javapackager。此類工具已包含在Java中，但作爲刪除JavaFX的一部分從JDK 11中刪除。
- 通過爲 操作員提供模式匹配來增強語言instanceof。這將是JDK 14中的預覽功能。模式匹配可以更簡潔和安全地表示程序中的通用邏輯，主要是從對象中有條件地提取組件。
- 文本塊的第二個預覽，這是一種多行字符串文字，它避免了大多數轉義序列的需要，並以可預測的方式自動格式化字符串。文本塊將在需要時使開發人員可以控制格式，簡化Java程序的編寫，並增強字符串的可讀性。文本塊在JDK 13中進行了預覽；JDK 14迭代將添加轉義序列以管理顯式空白和換行控制。
- 不贊成使用Parallel Scavenge和Serial Old垃圾收集算法的組合。Java維護者認爲這種組合很少使用，但需要大量維護。
- 將ZGC（Z垃圾收集器）移植 到Windows。在恢復到提議的目標列表之後，此功能再次移至正式目標列表。
- 外部存儲器訪問API，引入了Java程序的API，可以安全有效地訪問Java堆外部的外部存儲器。該API應該可以替代Java程序訪問內存（包括nio.ByteBuffer和）的主要途徑sun.misc.Unsafe。新的API應該能夠在各種類型的內存上運行，包括本機，持久性內存和託管堆。API不可能破壞JVM的安全性。內存釋放應在源代碼中明確。該API有望幫助開發本機互操作支持，這是巴拿馬項目的目標。
- 棄用Solaris / Sparc，Solaris / x64和Linux / Sparc端口，以在將來的發行版中將其刪除。放棄對這些端口的支持將使OpenJDK貢獻者能夠加速新功能的開發。儘管Solaris和Sparc是Java最初的創建者Sun Microsystems的關鍵技術，但近年來，它們已被Linux OS和Intel處理器取代了其技術領域。