JDK 26 首項功能：JEP 504 將移除讓 Java 火紅 30 年的開國功臣 Java Applet

在網路科技發展的歷程中，許多技術隨著時代的變遷而誕生、成長，最終也隨著新技術的替代而逐漸褪去光彩。例如 Java Applet 在 1990 年代時曾經是風靡一時的網頁互動技術，但到 2025 年的現在將正式告別 Java 平台。

JEP 504 是 Java 開發團隊針對 Applet API 的正式移除提案。這項決定不僅是技術演進的必然結果，也反映了網路技術生態的重大轉變。對於資深開發者來說，它象徵著一個時代的結束；而對新一代的程式設計師而言，則是理解技術生命週期的重要案例。本文將介紹 JEP 504 所提出的 Applet API 移除計畫

前言

Applet 技術在 Java 早期發展階段時扮演了重要的角色，它允許開發人員在網頁中內嵌 Java 程式，以提供比靜態 HTML 更加豐富的互動體驗。然而，隨著網路瀏覽器生態的演變，Applet 技術面臨了嚴峻的挑戰。

雖然 JDK 中仍保留著相關的 API，但因為目前所有主流的網頁瀏覽器皆已經停止支援 Java Applet，所以開發者已無法在現代瀏覽器中執行 Applet 程式。

更重要的是，身為重要支援機制的安全管理器（Security Manager），也已經在 JDK 24 的 JEP 486 中被永久停用。這使得 Applet 這類不受信任的程式碼失去了可供測試的沙箱環境，導致無法確保它們不會危害使用者的系統。

隨著安全管理器的停用，Applet 技術的最後一塊基石也已被移除。如果我們繼續維護一套已無法使用且沒有未來的 API，不僅會增加平台的維護負擔，也會對開發人員造成混淆。因此，徹底移除 Applet API 成為 Java 平台演進的必然選擇。

Java Applet 移除歷程

2015 年：Google Chrome 宣布計劃停止支援 NPAPI（支援 Java 外掛的關鍵技術）
2017 年：JDK 9 中 JEP 289 標記 Applet API 和 appletviewer 工具為棄用狀態，當時網頁瀏覽器供應商就已在移除對 Applet 的支援
2018 年：JDK 11 中移除 appletviewer 工具，它允許在不使用瀏覽器情況下測試 Applet。從那時起，我們便無法再使用 JDK 工具去執行或測試 Applet
2021 年：JDK 17 中 JEP 398 標記 Applet API 為棄用並準備移除
2025 年：JDK 24 中 JEP 486 永久停用安全管理器，失去了執行 Applet 的必要沙箱環境

至此，已無任何理由保留這個未被使用且無法再被使用的 Applet API。

JEP 504 概觀

本功能的核心目標非常明確：完全移除 Java 平台中的 Applet API。根據提案內容，這次移除將包含整個 java.applet 套件（包括 Applet、AppletContext、AppletStub 和 AudioClip 等類別），以及其他相關的類別如 java.beans.AppletInitializer 和 javax.swing.JApplet 等。

同時，任何參考這些被移除類別和介面的 API 元素，也會一併被調整或移除。

優點

精簡 Java 平台：移除不再使用的 API 可以減少 JDK 的複雜度和維護成本，讓開發團隊能專注於更有價值的功能開發
消除混淆：對於新手開發者來說，移除已無法使用的 API 可避免他們嘗試使用這些過時技術，減少學習過程中的困惑
促進替代方案的採用：明確移除 Applet API 將鼓勵仍在使用此技術的開發者轉向更現代的解決方案，如 JavaScript、WebAssembly 或其他 Web 技術
提升安全性：Applet 技術存在許多已知的安全問題，完全移除相關 API 可以減少潛在的安全風險
技術演進的自然過程：適時地淘汰過時技術是健康的技術生態系統的重要特徵，這有助於 Java 平台的長期健康發展

缺點

向後相容性問題：雖然 Applet 技術實際上已無法使用，但仍有可能存在依賴 Applet API 的舊有程式碼，這些程式碼將無法在新版 JDK 中編譯或執行
學習資源過時：許多 Java 教學資源可能仍包含 Applet 相關內容，這些資源將需要更新
部分方法行為改變：某些方法如 java.net.URL 和 java.net.URLConnection 類別的 getContent() 方法，其行為將因 AudioClip 的移除而改變，這可能影響依賴這些方法的程式
工具相容性：如 jtreg 等測試工具需要特別處理，以支援沒有 Applet API 的新版 JDK

介紹

以下 API 元素將會被移除：

整個 java.applet 套件，包含：
- java.applet.Applet
- java.applet.AppletContext
- java.applet.AppletStub
- java.applet.AudioClip
額外類別：
- java.beans.AppletInitializer
- javax.swing.JApplet
任何其他參考上述類別和介面的 API 元素，包括方法和欄位，位於：
- java.beans.Beans
- javax.swing.RepaintManager

風險與假設

考量到大多數的類別、介面和方法皆已無法使用，因此移除 Applet API 對使用者和應用程式應不會造成實質風險。如果仍然存在著使用 Applet API 的應用程式，理論上它們都會停留在舊版本，或者遷移到其他 API。在 Applet 類別作為使用者介面容器元件的情況下，AWT API 提供了多種替代方案。

java.net.URL 和 java.net.URLConnection 類別中 getContent() 方法的返回型別是 java.lang.Object。返回物件的精確型別取決於內容的型別；使用這些方法時，呼叫者必須測試返回物件的型別才能使用它。

歷史上，當內容是 JDK 內建內容處理器識別的音訊資料時，這些 getContent() 方法會返回 java.applet.AudioClip 的實例。隨著 Applet API 的移除，這將不再可能，並將返回其他型別的實例。將這些方法呼叫結果轉型為 AudioClip 的程式碼將無法編譯或執行，並將需要調整。

jtreg 工具參考了 Applet API，因此它必須使用仍支援 Applet 的 JDK 來建置。然而，無論如何這都是必要的，因為 jtreg 必須能夠測試比目前 javac 編譯器所支援更舊的 JDK 發行版本（release trains）。在執行時期，jtreg 僅在遇到基於 Applet 的測試時才會載入 Applet API，因此單一 jtreg 建置版本可以支援較舊的 JDK 建置版本以及省略 Applet API 的較新版本。