一句话总结：JEP 504 将彻底移除 Applet API，这项曾经推动 Java 风靡全球的技术，将在 JDK 26 中正式告别 Java 平台。

一、基本信息卡片

项目 内容
JEP 编号 504
标题 Remove the Applet API
类型 Feature（功能变更）
作用域 SE（标准版）
状态 Closed / Delivered（已关闭/已交付）
所属版本 JDK 26
组件 client-libs / java.awt
负责人 Philip Race
创建时间 2024 年 12 月 4 日
关联 JEP JEP 289（JDK 9 弃用 Applet API）、JEP 398（JDK 17 标记为待移除）、JEP 486（JDK 24 永久禁用安全管理器）

二、背景与动机

2.1 Applet 的前世今生

1990 年代，Java Applet 是网页交互的一颗明星。它允许开发者在网页中嵌入 Java 程序，为当时以静态 HTML 为主的网页带来了动画、游戏和复杂的交互能力。可以说，Applet 是 Java 平台早期成功的关键推手之一。

然而，技术浪潮从不停歇。2015 年，Google Chrome 率先宣布停止支持 NPAPI——这是浏览器运行 Java 插件的核心技术基础。随后，其他主流浏览器也纷纷跟进，彻底关闭了 Applet 的运行通道。

2.2 移除历程：一场持续近十年的告别

Applet API 的退出并非突如其来的决定，而是一个渐进、谨慎的过程：

  • 2017 年 · JDK 9（JEP 289）：首次将 Applet API 和 appletviewer 工具标记为弃用（Deprecated）。此时，浏览器厂商已在主动移除对 Applet 的支持。
  • 2018 年 · JDK 11：正式移除 appletviewer 工具。这个工具原本允许开发者在脱离浏览器的情况下测试 Applet。自此，JDK 中再无任何方式可以运行或测试 Applet。
  • 2021 年 · JDK 17（JEP 398）：将 Applet API 标记为“待移除”（Deprecated for Removal），向所有开发者发出最后通牒。
  • 2025 年 · JDK 24（JEP 486）：永久禁用安全管理器（Security Manager）。安全管理器是 Applet 沙箱机制的核心——它负责隔离不受信任的代码，防止恶意 Applet 危害用户系统。随着它的停用，Applet 失去了最后一块技术基石。

至此，Applet API 已经完全无法使用。继续保留一套既用不了也没有未来的 API，不仅增加 JDK 的维护负担，还可能对新开发者造成困惑。

三、核心变更详解

3.1 移除范围

JEP 504 将彻底移除以下 Java 平台 API 元素：

（1）整个 **java.applet** 包

该包中的所有类和接口将被完全删除：

类/接口 说明
java.applet.Applet Applet 基类
java.applet.AppletContext Applet 上下文接口
java.applet.AppletStub Applet 存根接口
java.applet.AudioClip 音频剪辑接口

（2）其他相关类

  • java.beans.AppletInitializer：Applet 初始化器
  • javax.swing.JApplet：Swing 版本的 Applet 类

（3）涉及引用的其他 API

移除 Applet API 后，其他 API 中引用上述类和接口的方法与字段也会被相应清理，包括：

  • java.beans.Beans 中的相关方法
  • javax.swing.RepaintManager 中的相关引用

3.2 迁移建议

对于仍有应用在使用 Applet API 的情况，JEP 提供了以下迁移路径：

  • UI 容器组件：如果 Applet 类仅作为用户界面的容器组件使用，AWT API 提供了多种替代方案。
  • 音频播放：如果 AudioClip 类仅用于音频播放，JDK 25 中引入的 javax.sound.SoundClip 类可作为替代。

四、与历史版本的关联

JEP 504 与以下 JEP 和变更紧密相关：

关联项 版本 作用
JEP 289: Deprecate the Applet API JDK 9 首次弃用 Applet API
JEP 398: Deprecate the Applet API for Removal JDK 17 标记为“待移除”
移除 appletviewer 工具 JDK 11 移除了 Applet 的测试工具
JEP 486: Permanently Disable the Security Manager JDK 24 禁用 Applet 依赖的沙箱机制

五、测试与兼容性

5.1 测试影响

所有依赖 Applet API 的测试都需要更新、禁用或移除。对于主 JDK 仓库中基于 jtreg 的测试，这项工作已基本完成。实际上，大多数相关测试只是借用了 Applet API 作为便利工具，而非专门测试该 API 本身。

5.2 兼容性风险评估

JEP 认为移除 Applet API 对用户应用的风险极小，理由如下：

  1. API 已长期无法使用：自 JDK 11 移除 appletviewer 以来，开发者已无法使用 JDK 运行 Applet。
  2. 浏览器全面停止支持：主流浏览器早已不再支持 Java 插件。
  3. 充分的缓冲期：从首次弃用（2017 年）到最终移除（2026 年），开发者拥有近 9 年的时间进行迁移。

对于仍有 Applet API 依赖的应用，可以选择继续停留在旧版本 JDK 上，或迁移至替代方案。

5.3 社区反馈

在 JEP 504 的讨论过程中，也有社区成员表达了不同看法。有开发者指出，他开发的 IDE 插件（支持 IntelliJ IDEA、Eclipse、NetBeans 在 IDE 内嵌运行 Applet）自 2021 年以来下载量已超过 5 万次，此外他还有超过 20 个 Swing 应用同时提供 Applet 形态。他还提到，CheerpJ 和 TeaVM 等工具可以通过 WebAssembly 在浏览器中运行 Applet。

对此，JEP 负责人 Philip Race 回应称：JEP 已充分阐明移除理由；依赖 Applet 的开发者已获得 8 年以上的迁移通知；即便未来通过 WebAssembly 等技术在浏览器中使用 Java，也不会选择重新启用这套过时的 Applet API。

六、小结与展望

JEP 504 标志着一个时代的正式终结。Applet API 的移除不是一次仓促的“手术”，而是一场跨越近十年、循序渐进的技术告别。从 JDK 9 的首次弃用，到 JDK 11 移除 appletviewer，再到 JDK 17 标记“待移除”和 JDK 24 停用安全管理器，每一步都在为最终的移除铺路。

对于 Java 平台而言，移除长期无人维护且无法使用的 API，是保持平台健康演进的重要举措。它减少了代码库的维护成本，降低了新开发者的认知负担，也让 JDK 能够将精力集中在更有价值的功能上。

Applet API 完成了它的历史使命。对于老一辈 Java 开发者，它是一个时代的记忆；对于新一代开发者，它是一个理解技术生命周期管理的生动案例。Rest in peace, Applet API.

参考文献：