Summary
-------

Deprecate the [RMI Activation](https://docs.oracle.com/en/java/javase/14/docs/specs/rmi/activation.html)
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](https://docs.oracle.com/javase/8/docs/api/java/rmi/activation/package-summary.html#package.description).
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](https://docs.oracle.com/en/java/javase/14/docs/api/java.rmi/java/rmi/activation/package-summary.html)
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](https://docs.oracle.com/en/java/javase/14/docs/api/java.rmi/module-summary.html)
module specification.

- Add a notice of deprecation to the
[RMI Activation](https://docs.oracle.com/en/java/javase/14/docs/specs/rmi/activation.html)
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](https://docs.oracle.com/en/java/javase/14/docs/specs/man/rmid.html)
tool to emit a warning message about deprecation.

- Add warning notices to the
[rmid tool documentation page](https://docs.oracle.com/en/java/javase/14/docs/specs/man/rmid.html).
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](https://river.apache.org/) project contains forked versions of RMI and
[Jini](https://en.wikipedia.org/wiki/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.