JavaSE 功能

Java 平台一直以其安全性與穩定性著稱，而這個優勢來自於持續不斷的改進與優化。為了要加強 Java 平台的安全性，自 JDK 24 的 JEP 498 起，每當我們在使用 sun.misc.Unsafe 中已棄用的記憶體存取方法時，都會產生警告提醒。 身為淘汰計畫中的一環，本功能是繼 JDK 23 中 JEP 471 之後的延續性改進，以藉此逐步淘汰不安全的記憶體存取方法，並引導開發者使用更安全、更標準化的 API。它不僅關係到平台的安全性提升，更攸關到許多仰賴這些 API 的函式庫與應用程式。本文會介紹這項變革的背景、目的與實施方式。 前言 如同老喬之前在 JEP 471 棄用 sun.misc.Unsafe 中的記憶體存取方法中提到的，在 2002 年 Java 發展的早期階段，為了滿足某些特殊的效能需求，平台引入了sun.misc.Unsafe 類別。 它提供了一系列讀寫記憶體的低階方法，包括使用原始指標讀寫 Java 物件、在記憶體間進行複製，以及分配與釋放原生記憶體等功能，讓開發者能夠直接存取和操作記憶體。 Unsafe 類別在當時確實解決了一些效能瓶頸，也一直是許多高效能 …

隨著垃圾回收機制的持續演進，效能優化一直是項重要的焦點。Java 24 的重要提案 JEP 490 將 Z 垃圾回收器（ZGC）完全轉向分代模式，並捨棄原有的未分代模式。這項提案主要著重在簡化 ZGC 的維護工作，並為未來的功能開發鋪路。 前言 ZGC 全名是 Z Garbage Collector，它是 Java 虛擬機器中一種新型的垃圾回收器，目的是為了實現低延遲和高擴展的垃圾收集器。首先在 JEP 333: ZGC: A Scalable Low-Latency Garbage Collector (Experimental) 中於 JDK 11 時以實驗性質的方式導入，之後在 JDK 13（JEP 351）和 JDK 14（JEP 364、JEP 365）中陸續有新功能加入，並且在 JDK 15（JEP 377）時正式成為可正式使用的產品功能。 它具有下列優點： 導入分代模式後 在 JDK 21 時加入了 JEP 439 ZGC 分代模式之後，同時維護兩套不同的垃圾回收模式成為 OpenJDK 開發團隊的重大負擔。目前的 ZGC 支援分代與未分代兩種模式，這種雙軌並行的架構造成 …

Java Native Interface（JNI）長期以來一直是 Java 平台與原生程式碼互動的重要橋樑。然而，老舊過時的互動方式帶來了安全性與完整性的隱憂。為此，JDK 24 推出 JEP 472，目的是為了要限制 JNI 的使用，同時也調整了外部函式和記憶體 API（FFM）的行為。 在去年九月老喬介紹本功能做為 JDK 24 的第一項功能，能幫助我們為未來的 Java 版本做好準備。接下來本文將介紹 JEP 472 的重要變更，並說明這些改變會如何影響我們的工作。 前言 JNI 自 JDK 1.1 推出以來，一直是 Java 程式碼與原生程式碼（通常是 C 語言）之間交互操作的主要管道。它允許 Java 程式碼呼叫原生程式碼（downcall，下行呼叫），以及原生程式碼呼叫 Java 程式碼（upcall，上行呼叫）。 不幸的是，它們之間的任何交互操作都是有風險的，很可能會損害應用程式和 Java 平台本身的完整性。根據「預設完整性」政策，所有能夠破壞完整性的 JDK 功能都必須獲得開發人員的允許。 一、下行呼叫的風險 Java 程式碼透過 JNI 呼叫原生程式碼的下行呼叫可 …

各位 Java 開發者，你們準備好迎接 Java 24 到來了嗎！XD 作為 2025 年第一個主要版本更新，Java 24 預計將於 2025 年 3 月 18 日正式發布，並帶來一系列令人期待的新功能和改進。除了上一版中重要的預覽特性會轉為正式功能之外，它還包含了多項全新功能，以及若干實驗性的改進。 本文將簡介 Java 24 中的 24 項 JEP（JDK Enhancement Proposals）。它們涵蓋了垃圾收集器優化、安全性增強、程式設計範式的改進，以及重要的 API 更新，這些功能將為 Java 開發者帶來更好的開發體驗和更強大的功能支持。 前言 Java 24 是目前 Java SE 平台的最新版本，尚處於初始候選版本階段，並預計於今年三月正式發布。 目前的初始候選版本中包含許多新功能，例如在效能優化方面引入了實驗性的分代 Shenandoah 垃圾收集器（JEP 404）和壓縮物件標頭（JEP 450）功能，同時也改進了 G1 收集器的屏障擴展機制（JEP 475）。這些改進將為 Java 應用程式提供更好的記憶體管理效能。 在安全性方面新增了量子電腦防禦機制，包 …

在 Java 開發生態系統中，類別檔案（Class File）的處理一直是重要但複雜的議題。JDK 23 中的 JEP 466 提出了標準化的 API，旨在簡化 Java 開發者處理類別檔案的工作流程，包括解析、生成和轉換等操作。 新的 API 不僅提供了更高層次的抽象層與更友善的介面，還透過現代 Java 語言特性的運用，為開發者帶來更直觀且更安全的類別檔案處理方式。本文簡介這項重要的預覽 API 更新，並說明它如何改善當前的開發體驗。 前言 在 Java 中，許多框架和工具都需要處理類別檔案，我們可以說它是 Java 生態系統的通用語言。解析、生成和轉換類別檔案的需求無處不在，我們可以使用獨立的工具和程式庫去檢查和擴展程式，而不會危及原始碼的可維護性。 目前有許多用於解析和生成類別檔案的程式庫，每個程式庫都有不同的設計目標、優點和缺點。處理類別檔案的框架通常會使用某個類別檔案程式庫，例如 ASM、BCEL 或 Javassist。然而，這些常用的解決方案存在著一些明顯的問題。 為何需要新的類別檔案 API？ 首先，現有的工具都有其特定的設計目標和限制，導致開發者需要在不同場景下根據 …

在軟體開發周期中，效能優化一直是重要的課題。Java 作為企業級應用程式開發的主流語言之一，持續不斷地追求更好的執行效能。JDK 23 中的 JEP 469 提出的向量 API（Vector API），正是朝向這個目標邁進的重要一步。 這個新的 API 目的是為了要提供一個簡潔且高效的向量計算介面，讓開發人員能夠更好地利用現代處理器的向量運算能力，從而大幅提升程式的執行效能。由於尚在孵化階段，因此本篇僅簡介功能，待功能正式上線後再詳細介紹。 前言 在傳統的程式開發中，我們常常要處理大量的數值運算，特別是在科學計算、機器學習、圖形處理等領域。這些運算通常會透過迴圈逐一處理每個數值，但是這種方式並沒有充分利用到處理器的特性。 目前的處理器都具有向量運算的能力，也就是所謂的 SIMD（Single Instruction Multiple Data）指令集。這些指令可以在一個時鐘週期內同時處理多個數值，理論上可以大幅提升運算效能。然而，在 Java 中不太容易直接利用這項能力。 為什麼我們需要向量計算 API？ 向量計算由一系列的向量操作所組成。向量通常包含一組固定的標量值（scalar v …

為了達成 Write once, run anywhere 的目標，早期的 Java 平台中隱含了未正式開放的程式碼，以利程式在不同的作業系統中與記憶體溝通。在 JEP 454 Foreign Function & Memory API（官方規格）發表之後，JDK 23 中 JEP 471 提出要棄用並最終移除 sun.misc.Unsafe 類別中的記憶體存取方法。 這項提案的目的是為了鼓勵開發者使用更安全、更標準的 FFM API，從而提高 Java 應用程式的整體穩定性和安全性。本文將深入探討 JEP 471 的背景、動機、以及對 Java 開發者的影響。我們將分析這項變更的優缺點，並提供程式碼範例說明如何從使用 sun.misc.Unsafe 遷移到推薦的替代方案。 前言 sun.misc.Unsafe 類別自 2002 年引入以來，一直是 Java 開發者執行低階操作的重要工具。它的大多數方法（87 個中的 79 個）用來存取記憶體，無論是在 JVM 的垃圾收集器中或是在不受 JVM 控制的堆外記憶體中。 然而，正如其名稱所暗示，sun.misc.Unsafe 類別中 …

身為 Java 開發人員都應該知道，當我們想要查詢某隻 API 的功能和用法時，我們會查看該 API 的 JavaDoc 以取得更多資訊。另外當我們需要提供函式庫讓他人使用時，撰寫 JavaDoc 亦是必要的程序。JDK 23 中的 JEP 467 針對既有的 JavaDoc 做出了改進，因為長久以來撰寫 JavaDoc 這件繁瑣的事情深深困擾著開發人員。 JEP 467 改變了我們對 JavaDoc 的認知。它為 JavaDoc 工具引入 Markdown 語法支援，徹底改變 Java 開發者撰寫 API 文件的方式。這項更新不僅簡化了文件撰寫過程，還提高了可讀性和維護性。本文將深入探討其實現方式、語法細節，以及它如何與現有的 JavaDoc 系統共存，為 Java 開發社群帶來更現代化、更靈活的文件編寫體驗。 前言 在 Java 推出之前，已有程式語言和工具支援文件註釋的功能，像是 Lisp（釋出於 1950 年代）允許開發人員在寫程式時，使用 docstrings 語法（開始於 1970 年代，其後發展成語言標準）提供內嵌文件註釋，並且可透過開發工具瀏覽和查詢。不過，其他大多數的 …

Java 8 引入的 Stream API 為開發者提供了強大且清楚易懂的方式來處理資料串流集合。然而，隨著時間的推移，開發者們發現 Stream API 在某些複雜場景下仍然有不少的局限性。本文將介紹 JDK 23 Stream API 的重大進化如何去填補這些缺失的拼圖：JEP 473 的新功能 Stream Gatherers 串流聚集器。 JEP 473 Stream Gatherers 串流聚集器目的在加強 Stream API 的功能，使其能支援自定義的中間操作。這項新特性將允許開發者以更靈活的方式轉換資料流，解決了許多現有 Stream API 難以處理的複雜場景。接下來，讓我們深入探討串流聚集器會如何改變 Java 開發者處理資料串流的方式。 前言 Java 8 新增專為 lambda 表達式設計的第一個 API：Stream API（java.util.stream）。串流是一個惰性計算的、可能無邊界的資料序列，而 Stream API 支援循序或並行處理串流的能力。一個串流管道由三個部分組成：元素的來源、任意數量的中間操作和一個終端操作。例如： 這種程式設計風格既有 …

在執行緒並行的應用程式中，如何做資料共享一直是個重要且棘手的議題。Java 平台長期以來使用 ThreadLocal 來實現執行緒內的資料共享，但是這種方式存在著一些缺陷。為了解決這些問題，Java 引入了一個新的功能：JEP 481 Scoped Values（範圍值）。 本文將探討 Scoped Values 範圍值的核心概念、設計動機、實現方式，以及與 ThreadLocal 相比的優勢。我們將通過實際的程式碼範例，展示如何實際運用這個新功能，以及它如何能夠改變我們的程式設計思維。 前言 ThreadLocal（執行緒局部變數）在 Java 1.2 時引入，提供了一種在執行緒內不同方法之間共享資料的便捷方式。然而，隨著時間的推移，其設計缺陷慢慢地顯現出來，例如：記憶體洩漏、記憶體開銷、變數值可以被修改等等。這些缺點導致雖然它在某些情況下很有用，但是執行時會造成異常拋出或未預期的錯誤。開發者需要仔細考慮這些缺點，並根據具體情況選擇更合適的資料共享機制。 ThreadLocal 的缺點 首先，ThreadLocal 變數預設具有不受限制的可變性，這代表著任何可以訪問它的程式碼都可以在 …