JEP 385: Deprecate RMI Activation for Removal

Summary

Deprecate the RMI Activation mechanism for future removal. RMI Activation is an obsolete part of RMI that has been optional since Java 8. No other part of RMI will be deprecated.

Motivation

RMI Activation is Effectively Obsolete

Distributed systems have been based on web technology for at least the past decade. Concerns about traversing firewalls, filtering requests, authentication, and security have all been addressed in the web services space. Lazy instantiation of resources is handled by load balancers, orchestration, and containers. None of these mechanisms is present in the RMI Activation model for distributed systems.

RMI Activation is Mostly Disused

There is vanishingly small usage of RMI Activation. There is no evidence of any new applications being written to use RMI Activation, and there is evidence that very few existing applications use RMI Activation. A search of various open source code bases has revealed barely any mention of any of the Activation-related APIs. No externally-generated bug reports on RMI Activation have been received for several years. A query on the Stack Overflow Q&A website reveals about 2,200 questions about RMI, but only 14 of them mention "activation". The most recent JavaRanch forum question about RMI Activation was posted in 2003, whereas that forum receives dozens of posts on other topics on a daily basis.

RMI Activation was made optional in Java 8. There were no objections to on this specification change, nor have there been any bug reports concerning the optionality of Activation.

RMI Activation Imposes an Ongoing Maintenance Burden

Maintaining RMI Activation as part of the Java Platform incurs continuing maintenance costs. It adds complexity to RMI. RMI is still being maintained, and RMI Activation increases the expense of that maintenance.

RMI Activation has a suite of tests in the JDK. These tests typically invoke the RMI Activation service (rmid) as well as a client and a server JVM. This causes the tests to run slowly, and the multi-process nature of these tests results in a steady stream of intermittent, spurious failures.

The specification, implementation, and tests for RMI Activation all impose continuing maintenance overhead. RMI Activation can be removed without affecting the rest of RMI. Removal of RMI activation does not reduce Java's value to developers, but it does decrease the JDK's long term maintenance costs.

Description

The RMI Activation mechanism allows RMI-based services to export stubs whose validity exceeds the lifetime of a remote object or a JVM that contains it. With conventional (non-Activatable) RMI, a stub becomes invalid as soon as a remote object is destroyed. Recovering from this situation requires clients to implement complex error-handling logic. When a client invokes a method on an activatable stub, the RMI Activation service instantiates the remote object on-demand, alleviating clients of the burden of dealing with invalid stubs. This seems like a valuable mechanism, however, as described in the Motivation section, the amount of actual usage of RMI Activation is vanishingly small.

This JEP will deprecate the RMI Activation mechanism for future removal. This entails making the following changes to the Java Platform:

• Add @Deprecated(forRemoval=true) to all public classes and interfaces that reside in the java.rmi.activation package.

• Add a @deprecated javadoc tag and explanation to the java.rmi.activation package declaration.

• Add a notice of deprecation of Activation to the java.rmi module specification.

• Add a notice of deprecation to the RMI Activation chapter of the RMI Specification.

The following changes will also be made to the JDK:

• Add @Deprecated(forRemoval=true) to the com.sun.rmi.rmid.ExecOptionPermission and ExecPermission classes and to the com.sun.rmi.rmid package.

• Change the rmid tool to emit a warning message about deprecation.

• Add warning notices to the rmid tool documentation page. This will include notice of deprecation of the rmid tool itself. It will also include notice of deprecation of the permission classes in com.sun.rmi.rmid, since this page appears to be the only place in the JDK where these permission classes are documented.

Alternatives

Leave RMI Activation in Place

One alternative is leave RMI Activation in place, as has been the case for the past several years. It will continue to impose an ongoing quality risk and maintenance burden. The ongoing costs are continual, and are not justified by the minimal value that this essentially unused mechanism is bringing to the platform.

Remove RMI Activation from JDK Builds

RMI Activation is an optional part of the Java Platform, and therefore it could be omitted from JDK builds. The actual implementation could be removed and replaced with methods that throw UnsupportedOperationException. The tests could also be removed.

However, the JDK is the reference implementation of the Java Platform, and reference implementations are required to include all optional features so that they can be tested. Thus, the RMI Activation implementation and tests could not simply be removed from the JDK. They would instead have to be conditionally configured in by the build system. Activation would be included for reference implementation builds, so that it could be tested properly, and it would likely be omitted from production builds.

This would increase the complexity of the system. The build process would need to be enhanced to support both modes. Continuous integration systems would need to add runs to build and test both configurations. The implementation and tests are still present in the system and must continue to be maintained on an ongoing basis. Removing RMI Activation from JDK builds would therefore not reduce the overall maintenance burden, which is the goal of this JEP.

Risks and Assumptions

There is the possibility that third party products use Activation, and thus they would be impacted by its deprecation and eventual removal. This is unlikely, given the lack of input received on changes to Activation over the last several years. Activation still exists in earlier JDK releases, some of which have long-term support. Applications that depend upon Activation can continue to rely on existing supported JDKs for some time, while migrating to newer technologies.

The Apache River project contains forked versions of RMI and Jini technology, including an activation mechanism. This part of River depends upon Java’s java.rmi.activation types. Removal of RMI Activation from Java will prevent the River project from migrating to the latest versions of Java, unless they are able to remove the dependency on the Java types.