文/廠商新聞稿 | 2021-09-24發表

甲骨文正式發布 Java 17，這是備受歡迎的程式設計語言和開發平台最新推出的版本。Java 17 提供了數千種性能、穩定性和安全性更新，以及14 個JEP(JDK Enhancement Proposal) 來進一步優化 Java 語言和平台，從而協助開發人員提高工作效率。

甲骨文每六個月如約發布新版本的 Java，而 Java 17 是最新發布的 長期支援 (Long-Term Support, LTS) 版本。此版本是甲骨文的工程師與全球 Java 開發人員社區的成員透過 OpenJDK 社區 和 JCP (Java Community Process) 共同合作的成果。自三年前發布 JDK 11 LTS以來，甲骨文已經實施了超過 70 項 JEP。

提供更簡單的許可證

甲骨文將從 Oracle JDK 17 發行版本開始提供免費使用的許可證，並在下一個 LTS 版本發布之後繼續提供整整一年。同時，甲骨文也將延續自 2017 年以來的做法，繼續根據開源通用公共許可證 (GPL) 發布 Oracle OpenJDK 發行版本。

增強對客戶的長期支援

甲骨文與 Java 開發人員社區和 JCP 合力優化 LTS 計畫，如果組織希望遷移到較新的 Java LTS 版本，他們將擁有更大的靈活性，並且可以更好地掌控時間。下一個 LTS 版本將會是 Java 21，於 2023 年 9 月推出，LTS 版本的發布週期將從現有的三年縮短至兩年。

Oracle LTS 和 Java SE 的訂閱客戶可以按自身計畫遷移到 Java 17。甲骨文將為客戶提供 Java 17 的安全性、性能和錯誤修復更新，至少到 2029 年 9 月。

甲骨文 Java 平台開發副總裁 Georges Saab 表示：「在過去的三年裡，許多開發人員都很喜歡這些新功能，我們看到生態系統真正適應了每六個月一次的發布節奏。Java 開發人員目前面臨的一大挑戰是，他們的組織只允許使用最新的 LTS 版本。現在，LTS 版本將改為每兩年發布一次，組織較為保守的開發人員也可以選擇和連結他們喜歡和想要使用的功能。」

IDC 軟體發展研究副總裁 Arnal Dayaratna 表示：「甲骨文正在做出改變，不僅將長期支援版本的發布週期改為兩年，同時新推出的許可證也更寬鬆，延長了生產環境的 Oracle JDK 免費使用期限，讓 Java 社區獲益無窮。因此，組織可以更靈活地管理雲、本地和混合環境中複雜的現代應用程式開發和部署。」

加快 Java 在雲中的採用

Java 是一個成功的開發平台，以滿足開發人員不斷變化的需求為目標而持續進行創新。為了加速 Java 在雲中的採用，甲骨文最近推出了 Oracle Java 管理服務 (Oracle Java Management Service)，這是一項新的 Oracle 雲端基礎設施 (OCI) 原生服務，可幫助組織在本地或任何雲端上管理 Java 運行時與應用程式。

Oracle Java 管理服務能夠協助客戶瞭解整個企業中的Java部署，這涵蓋了安裝在企業環境中的所有 Java 版本，及在開發和生產中運行的 Java 版本。Oracle Java 管理服務能夠突顯任何未計畫運行的 Java 應用程式，並檢查所有已安裝的 Java 版本是否安裝了最新的安全補丁，確保版本即時更新。

JDK 17 增加了新的語言增強功能，對函式庫進行更新，支援新款 Apple 電腦，移除和棄用舊功能，並且確保用戶編寫的 Java 代碼在未來的 JDK 版本中可以繼續正常工作。此外，JDK 17 還提供語言功能預覽版和孵化階段的 API，以收集來自 Java 社區的回饋。具體更新內容包括：

Java 語言增強功能

  • JEP 409：密封類 — 密封類和介面限制其他類別亦或是介面可以擴展或實施它們。此增強功能是Project Amber的又一項改進，旨在透過發展 Java 語言來提高開發人員的生產力。

對函式庫進行更新和優化

  • JEP 306：恢復始終嚴格的浮點語義 — Java 程式設計語言和 Java 虛擬機器最初只有嚴格的浮點語義，從 Java 1.2 開始，為了適應當時硬體架構的限制，曾默認允許這些嚴格語義中的細微變化。現在不再需要這些變化，已在 JEP 306 刪除。

  • JEP 356：增強型偽亂數產生器 — 增加偽亂數產生器 (PRNG) 的新介面類別型和執行方法，提高了不同 PRNG 的互通性，並且易於根據需求請求演算法，而不是對特定的執行內容進行硬編碼。

  • JEP 382：新的 macOS 渲染管道 — 透過使用新的 Apple Metal API 為 macOS 實施Java 2D 渲染管道，減少了 JDK 對已棄用的 Apple OpenGL API 的依賴。

支援新平台

  • JEP 391：macOS AArch64 — 將 JDK 移植到 macOS/AArch64 平台，Java 應用可以原生運行於基於 Arm 64 的新 Apple Silicon 電腦。

移除和棄用

  • JEP 398：棄用即將移除的 Applet API — 所有 Web 瀏覽器供應商正計畫或已經停止支持 Java 瀏覽器外掛程式。Applet API 已於 2017 年 9 月在 Java 9 中棄用，但並未移除。

  • JEP 407：移除 RMI 啟動 — 移除遠端方法調用 (RMI) 啟動機制，保留其他 RMI。

  • JEP 410：移除實驗性的 AOT 和 JIT 編譯器 — 以Java為基礎的預先 (AOT) 和即時 (JIT) 實驗性編譯器並未被廣泛採用。作為一個選擇性功能，AOT 和 JIT 編譯器已在 JDK 16 中移除，本次在 JDK 原始程式碼中移除。

  • JEP 411：棄用即將刪除的安全管理器 — 從 Java 1.0 開始，安全管理器一直都不是保護用戶端 Java 代碼的主要手段，也很少用於保護伺服器端代碼。在未來的版本中會移除安全管理器，以消除大量維護負擔，讓 Java 平台能夠持續發展。

朝向未來的Java程式

  • JEP 403：JDK 內部強封裝 — 用戶再也不能像在 JDK 9 到 JDK 16 中一樣，透過單個命令列選項來放寬對內部元素的強封裝。使用者仍然可以連結現有的內部 API ，但需要以命令列參數形式或 JAR 檔清單屬性進行，且每個套組應該放寬封裝。此更改將使應用程式更安全，並減少對非標準、內部 JDK 實施細節的依賴。

未來JDK發行版本的預覽版和孵化器

  • JEP 406：Switch 模式比對(預覽版)— 允許Switch運算式針對多個模式進行測試，每個模式都有特定的操作，從而簡潔、安全地表達資料導向式的複雜查詢。

  • JEP 412：外部函數和記憶體 API(孵化階段)— 改進 JDK 14 和 JDK 15 中引入的孵化 API，讓 Java 程式與 Java 運行時之外的代碼和資料進行交互操作。透過有效調用外部函數(即 JVM 之外的代碼)，以及安全地連結外部記憶體，這些 API 可以調用本地函式庫和處理本地資料，並且不受 Java 本機介面 (Java Native Interface, JNI) 的脆弱性和複雜性影響。這些 API 正在Project Panama中開發，目的是改進 Java 和非 Java 代碼之間的交互性。

  • JEP 414:向量 API(二次孵化階段)— 允許以一種在運行時，可靠地編譯為支援的 CPU 架構上的最佳向量指令的方式表達向量計算，從而優化等效標量計算的性能。

其他資源

關於甲骨文

甲骨文公司在Oracle雲端服務中提供一系列整合應用程式和安全、自主的基礎設施。如需瞭解更多關於甲骨文公司(NYSE:ORCL)的資訊，請點閱：www.oracle.com或www.oracle.com/tw

熱門新聞

Advertisement