Java24

作為 Java 平台的元老級功能之一，Security Manager 安全管理器自 Java 誕生之初就扮演著程式碼安全守門員的角色。然而，隨著時代演進，它的存在價值已經逐漸消失。 因此，JDK 24 的 JEP 486 中預計徹底移除安全管理器，並為 Java 開發帶來更簡潔且更現代化的安全機制。本文將深入探討為何要移除安全管理器，以及分析其對於 Java 開發生態系統的影響。 前言 這些年以來，Security Manager 安全管理器已經不再是保護客戶端 Java 程式碼的主要手段。而且，它在伺服器端的應用也極為罕見，並且維護成本高昂。 SecurityManager 的設計理念是最低權限原則（principle of least privilege），意即預設讓程式碼處於不受信任的狀態，並且需要明確授予權限後才能存取系統資源。理論上，它可以有效防範惡意程式碼或意外漏洞，但實際執行時卻面臨許多挑戰。 首先是權限管理機制過於複雜，導致了大多數開發人員完全停用安全管理器，或是乾脆給予全部權限，使得安全管理形同虛設。更糟糕的是，為了維持安全管理器的運作，Java 平台函式庫必須將權 …

Java 虛擬機器一直以來都支援跨平台和動態特性，但這種靈活性往往伴隨著效能損耗，特別是在程式啟動階段。Java 24 的 JEP 483 引入了預先類別載入與連結機制，為這項長期存在的問題提供了優雅的解決方案。 本功能可讓 HotSpot JVM 在程式啟動時，直接使用預先準備好的類別資訊，以避免重複進行費時的載入與連結作業。根據初步測試，它可以為程式縮短 42% 的啟動時間，對於企業級別的應用場景特別有用。 前言 Java 平台的重要特色之一是高度動態性，包括動態類別載入、動態連結、動態配發，以及動態反射等機制，給予開發者極大的表達能力。例如： 此外，動態編譯、動態反最佳化與動態記憶體回收等機制，也為 JVM 提供極大的彈性： 動態性帶來的啟動成本 然而，這種高度動態的機制是需要付出代價的，而且這個代價必須在程式每次啟動時付出。以一個典型的伺服器應用程式的啟動過程來說，JVM 會交錯執行多種工作： 若是再加上應用框架的話（例如 Spring），那麼還會增加額外的啟動開銷。因為 Spring 會掃描 @Bean、@Configuration 等註解，並進行組態探索，導致進一步影響啟動 …

隨著雲端運算的普及，降低 JVM 的整體開銷變得日益重要。Java 24 中的 JEP 475 為 G1 垃圾回收器帶來重大的技術改進，使得 G1 垃圾回收器的實作能夠更加簡化，並且可以更有效地追蹤應用程式的記憶體存取行為。 這項提案的靈感來自於 ZGC 的成功經驗。它自 JDK 14 就開始延後了屏障擴展步驟（late barrier expansion），並在 JDK 15 中達到正式可用的穩定性。因此，把此一技術導入 G1 可以為開發人員帶來更好的執行效能，與更低的系統資源消耗。 前言 雖然 JIT 編譯能夠有效地提升 Java 程式的執行效率，但同時也帶來明顯的處理時間與記憶體用量上升。初步實驗顯示，在名為 C2 的 JIT 編譯器上，如果在編譯早期就擴展 G1 屏障（barrier），會增加約 10-20% 的額外開銷（因程式而異）。因為在 C2 的中介表達式（IR，Intermediate Representation）中，每個 G1 屏障會被擴展為 100 個以上的操作，並最終轉換成約 50 條 x64 指令。因此，降低這類開銷對於提升 Java 平台在雲端環境中的效能就 …

在 Java 開發生態系統中，類別檔案（Class File）的處理一直是重要但複雜的議題。在歷經了前兩個版本的預覽後，類別檔案 API 終於在 JDK 24 的 JEP 484 中做為正式功能發佈，以簡化 Java 開發者處理類別檔案的工作流程，包括解析、生成和轉換等操作。 新的 JEP 484 API 不僅提供了更高層次的抽象層與更友善的介面，還透過現代 Java 語言特性的運用，為開發者帶來更直觀且更安全的類別檔案處理方式。本文將詳細介紹這項重要的 API 功能，並說明它如何改善當前的開發體驗。 前言 在 Java 中，類別檔案是 Java 生態系統中的通用語言。許多框架和工具都需要解析、生成和轉換類別檔案。我們可以使用獨立的工具和函式庫去檢查與擴展應用程式，而不會危及其原始碼的可維護性。例如，框架可以使用即時的位元組碼轉換來添加無法或很難包含在原始碼中的功能。 目前有許多用於解析和生成類別檔案的函式庫，例如 ASM、BCEL 或 Javassist。它們各自有著不同的設計目標、優點和缺點。我們通常會使用前述的其中一種函式庫去存取類別檔案，但是這些常用的解決方案存在著一些明顯的問 …

在 Java 23 中，引入了一項新的語法加強功能預覽：JEP 476 模組化的匯入宣告，讓我們可以更簡潔且高效地一次匯入整個模組函式庫中的類別，而無需使用原有的 single-type-import 和 type-import-on-demand 語法。 今年發佈的 Java 24 中，JEP 494 進行第二次的預覽，並伴隨著些微更新以回應社群的使用建議。它預計將於 Java 25 LTS 中成為正式功能，並開放給所有開發人員使用。本文將介紹 JEP 476 與 JEP 494 兩者之間的差異，提供大家做為未來的實作參考。 前言 前一版的 JEP 476（本站介紹）允許開發者透過單一陳述句去匯入模組中的所有公開型別，以簡化模組化函式庫的重複使用。有了這項功能，初學者便能更輕鬆地使用第三方函式庫和基礎 Java 類別，而無需學習它們在套件階層中的位置。它提供了簡潔的方式，將匯入類別與套件的語句簡化成匯入模組，以減少樣板程式碼撰寫： 模組匯入宣告的語法 JEP 476 的核心是引入了新的模組匯入 import module 語句，這允許開發人員一次匯入模組中導出的所有套件，減少了冗長的 …

在雲端運算與容器化技術盛行的今天，應用程式的部署效率與資源使用效率變得比以前更加重要。JDK 的安裝容量一直是持續討論的議題，特別是在需要頻繁下載、建置和部署容器映像的場景中。 Java 24 的 JEP 493 允許開發者在不使用 JMOD 檔案的情況下，也能透過 jlink 工具建立客製化的執行階段映像，預期可為 JDK 減少約 25% 的體積，大幅提升容器部署效率。 前言 在現代雲端環境中，容器技術已成為應用程式部署的主流方式。包裝映像的檔案大小是我們需要關注的重要議題。無論是基底映像下載、映像儲存、上傳新版映像、部署環境等步驟，我們都希望能夠縮小映像檔的體積。 因為經常需要從容器註冊中心下載並快速複製映像檔，所以如果可以減少體積的話，就代表著能夠減少流量和儲存成本，並且縮短作業時間和提升部署效率。以 JDK 來說，目前完整的 JDK 主要包含兩個部分： 什麼是 JMOD？ jmod 是自 Java 9 引入模組系統後新增的工具，其主要目的是為了提供更完整封裝 Java 模組的中介格式，以補足模組化的封裝和分發需求。傳統上，我們習慣使用 JAR 檔案封裝應用程式或函式庫，但 JA …

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 支援分代與未分代兩種模式，這種雙軌並行的架構造成 …