Applets 应用程序的终结

Oracle 在 JEP-398 中将 Applet 相关的 API 标记为 “已弃用”。在进入 21 世纪后，所有的主流浏览器都不再支持 Java Applets 所依赖的 NPAPI 插件，在这样的背景下，Oracle 多年来一直都在发布即将弃用 Applets 的公告（JEP-289）。

在若干年前浏览器的功能较弱、程序开发相关标准尚未完善的时候，Java Applets 就较早地做到了支持富互联网应用。支持 Java Applets 的能力是由 网景插件应用程序接口（简称 NPAPI）提供的，它能够在浏览器的沙盒环境下运行 Java 应用。NPAPI 第一次出现在浏览器中是在 1995 年，比 Mozilla 基金会的成立 (2005) 和 Chrome 的第一个版本 (2008) 都要早得多。

在现代浏览器标准出现之前，这些 Applets 应用层序通常被用于文件传输、用户鉴权以及处理各种 Javascript 在当时无法处理的情况。各大浏览器在 2015 年开始 移除对 NPAPI 的支持，以此简化浏览器的维护工作，并和 Oracle 发布的关于 Applets 的一份白皮书文件：从 Java Applet 迁移到无插件的 Java 技术 保持同步。

在 2015 年 API 的变化之前， Java Applet 应用的安全性就一直广为讨论，但许多组织能够通过使用管理工具 (例如：部署规则集) 或者在一个孤立的 Citrix 环境中将 Java 和浏览器的兼容性锁定在一起来保护客户端。

尽管在之前的 Java 版本中就已经为 Java Applets 打上了已被弃用的标签，但相关的 API 仍被暂时保留了下来，以防一些没有实际使用相关 API 却仍旧调用了相关 API 的应用程序遭遇编译或运行错误。事实上，在 Java 和 OpenJDK 平台近 20 年的标准文档中，Applet 这一特性都被标注为“已弃用”和“将被移除”。

InfoQ 与 Dr. Deprecator 以及 OpenJDK 的贡献者 Stuart Marks 进行了交流，探访 OpenJDK 项目是怎么界定、使用 @Deprecated 标签的，并了解都有哪些 API 已经被弃用。

Java 9 增强了 @Deprecated 弃用注解，为其新增了 forRemoval 属性。随着 JEP-398 提出的改变，Applet API 将被设置为 forRemoval = true，在这些 API 被真正移除前，forRemoval 属性将让编译器和相关工具为开发者弹出更严重的警告。通过渐进式地设置多个警告可以有效的避免开发社区内的代码混乱，这秉承了语言架构师 Brian Goetz 在 2015 年的演讲 “谨慎演进，避免破坏” 中所传达的思想。

已被从核心的 Java APIs 移除的其他项目包括：

• CORBA，一个互操作式框架，由对象管理组织 (OMG) 于 1991 年发布，其最新版本在 2012 年发布
• JAXB，一个 XML 相关 API 的集合，现在被置于 Jakarta EE 库中进行维护
• Nashorn，一个 JavaScript 执行引擎
• 一些小变化，例如 Thread.stop(Throwable), System.runFinalizersOnExit, 以及 RMI Stub Compiler

如果想知道上述改变是否会影响到他们的应用程序或者依赖，用户们可以尝试在代码和依赖中使用这两个工具：

• jdeps，这是一个能分析是否使用了有不兼容风险的 API 的工具。它可以帮助开发团队排查项目中是否使用了已经发生改变的、不规范的 API
• jdeprscan，这是一个能够分析 @Deprecated 弃用注解的工具，它会分析如果不对已弃用的 API 进行调整的话，项目会面临怎样的风险

当被问及 Applet 的弃用是否可以应用于序列化、Applet 安全管理器和一些其他方面时，相关提案者简单地回答道:“等着瞧吧（Hold my beer）”，这暗示着相关的更改可能已经正在进行了。