跳到主要内容

JEP 385：弃用 RMI 激活以进行删除

概括​

弃用RMI 激活机制以便将来删除。 RMI 激活是 RMI 的过时部分，自 Java 8 以来一直是可选的。RMI 的其他部分不会被弃用。

动机​

RMI 激活实际上已过时​

分布式系统至少在过去十年中一直基于网络技术。关于穿越防火墙、过滤请求、身份验证和安全性的担忧都已在 Web 服务领域得到解决。资源的延迟实例化由负载均衡器、编排和容器处理。分布式系统的 RMI 激活模型中不存在这些机制。

RMI 激活大多被废弃​

RMI 激活的使用非常少。没有证据表明任何新应用程序正在编写以使用 RMI 激活，并且有证据表明现有应用程序很少使用 RMI 激活。对各种开源代码库的搜索显示，几乎没有提及任何与激活相关的 API。多年来没有收到任何外部生成的有关 RMI 激活的错误报告。 Stack Overflow Q&A 网站上的查询显示了大约 2,200 个有关 RMI 的问题，但其中只有 14 个提到“激活”。关于 RMI 激活的最新 JavaRanch 论坛问题发布于 2003 年，而该论坛每天都会收到数十篇有关其他主题的帖子。

RMI 激活在Java 8中成为可选的。没有人反对此规范更改，也没有任何有关激活可选性的错误报告。

RMI 激活会带来持续的维护负担​

将 RMI 激活作为 Java 平台的一部分进行维护会产生持续的维护成本。它增加了 RMI 的复杂性。 RMI 仍在维护中，RMI 激活会增加维护费用。

RMI Activation 在 JDK 中有一套测试。这些测试通常调用 RMI 激活服务 ( rmid) 以及客户端和服务器 JVM。这会导致测试运行缓慢，并且这些测试的多进程性质会导致源源不断的间歇性、虚假故障。

RMI 激活的规范、实现和测试都会带来持续的维护开销。可以删除 RMI 激活而不影响 RMI 的其余部分。取消 RMI 激活并不会降低 Java 对开发人员的价值，但确实会降低 JDK 的长期维护成本。

描述​

RMI 激活机制允许基于 RMI 的服务导出其有效性超过远程对象或包含该对象的 JVM 的生命周期的存根。对于_传统的_（不可激活的）RMI，一旦远程对象被销毁，存根就会变得无效。从这种情况中恢复需要客户端实现复杂的错误处理逻辑。当客户端调用_可激活_存根上的方法时，RMI 激活服务会按需实例化远程对象，从而减轻客户端处理无效存根的负担。这看起来是一个很有价值的机制，但是，正如动机部分中所述，RMI 激活的实际使用量非常小。

此 JEP 将弃用 RMI 激活机制以供将来删除。这需要对 Java 平台进行以下更改：

  • 添加@Deprecated(forRemoval=true)到驻留在java.rmi.activation包中的所有公共类和接口。

  • 将@deprecatedjavadoc 标签和解释添加到java.rmi.activation包声明中。

  • 在java.rmi模块规范中添加弃用 Activation 的通知。

  • 在RMI 规范的RMI 激活章节中添加弃用通知。

JDK 还将进行以下更改：

  • 添加@Deprecated(forRemoval=true)到com.sun.rmi.rmid.ExecOptionPermission和ExecPermission类以及com.sun.rmi.rmid包中。

  • 更改rmid工具以发出有关弃用的警告消息。

  • 将警告通知添加到rmid 工具文档页面。这将包括该工具本身弃用的通知rmid。它还将包括弃用 中权限类的通知com.sun.rmi.rmid，因为此页面似乎是 JDK 中记录这些权限类的唯一位置。

备择方案​

将 RMI 激活保留在原处​

一种替代方法是保留 RMI 激活，就像过去几年的情况一样。它将继续带来持续的质量风险和维护负担。持续的成本是持续的，并且这种基本上未使用的机制为平台带来的最小价值并不能证明其合理性。

从 JDK 构建中删除 RMI 激活​

RMI 激活是 Java 平台的可选部分，因此可以在 JDK 构建中省略它。实际的实现可以被删除并替换为抛出异常的方法UnsupportedOperationException。测试也可以被删除。

但是，JDK 是 Java 平台的参考实现，参考实现需要包含所有可选功能，以便可以进行测试。因此，RMI 激活实现和测试不能简单地从 JDK 中删除。相反，它们必须由构建系统有条件地配置。激活将包含在参考实现构建中，以便可以正确测试它，并且可能会从生产构建中省略它。

这会增加系统的复杂性。需要增强构建过程以支持这两种模式。持续集成系统需要添加运行来构建和测试这两种配置。实施和测试仍然存在于系统中，并且必须继续持续维护。因此，从 JDK 构建中删除 RMI 激活不会减少总体维护负担，而这正是此 JEP 的目标。

风险和假设​

第三方产品有可能使用激活，因此它们会受到其弃用和最终删除的影响。鉴于过去几年缺乏关于激活更改的反馈，这种情况不太可能发生。早期的 JDK 版本中仍然存在激活，其中一些版本具有长期支持。依赖 Activation 的应用程序可以在一段时间内继续依赖现有支持的 JDK，同时迁移到更新的技术。

Apache River项目包含 RMI 和Jini技术的分叉版本，其中包括激活机制。这部分河流取决于爪哇的java.rmi.activation类型。从 Java 中删除 RMI 激活将阻止 River 项目迁移到最新版本的 Java，除非他们能够删除对 Java 类型的依赖。