New candidate JEP: 407: Remove RMI Activation
stuart.marks at oracle.com
Tue May 4 19:55:18 UTC 2021
JEP 407 is about removing all of these APIs and implementations. The deprecation
step was done by JEP 385, which was delivered in Java 15. I guess you're proposing
that this JEP should change to do something like removing the implementation while
leaving the APIs.
This can't be done, for a few reasons.
1. The point of having APIs in the JDK is for applications and external libraries to
use them to access abstractions and behaviors that are provided by the JDK. The JDK
is not in the business of maintaining APIs in support of abstractions and behaviors
it is no longer defining, providing, or specifying.
2. These APIs all have specifications that require certain behaviors. You can't just
leave the types around and nothing else. For example, the exception classes all have
constructors, and those constructors actually have to construct something. The
exceptions are all serializable, they have a well-defined serialization format, and
can be serialized and deserialized as well. The concrete classes have methods that
can be called. All these require specifications and behaviors that are tested. The
goal of this JEP is to remove from the JDK the burden of maintaining all of that.
3. There are a few places in the RMI internals where special-case treatment is
provided to activatable objects or stubs. These behaviors are internal only and
cannot be maintained after RMI Activation has been removed from the JDK. It's not
clear to me that Apache River or Phoenix will continue to work properly on a JDK
without Activation, even if all the APIs are left around, as they are likely to be
implicitly relying such behaviors.
As near as we can tell, there is vanishingly small usage of RMI Activation in the
Java community in general. RMI Activation (and RMI itself, for that matter) have not
evolved in the past 15 years or so. Furthermore, there has been virtually no demand
for new features or evolution of RMI-related technologies for most of that time.
It's hard to escape the conclusion that this it's all obsolete.
I can appreciate that this puts Apache River and Phoenix into a difficult position.
I don't think though that the answer is for the RMI APIs to hang around in future
versions of the JDK. I don't know if they'll help, but let me toss out a couple ideas:
- Several vendors offer long-term support for earlier releases of the JDK that
contain all the Activation APIs and implementations. These will continue to be
available for a significant period of time, allowing existing implementations to run
- As I noted above, the RMI-related technologies in the JDK haven't evolved for
the past 15 years. I can't help but think that this has been an impediment to
evolving things that are depending upon it. If Apache River/Phoenix continue to be
developed, it would be wise to develop a migration plan away from dependencies on
RMI-related APIs and implementations exist in the JDK. This will probably allow
River and Phoenix to get rid of a bunch of technical debt.
On 4/30/21 7:27 PM, Peter Firmstone wrote:
> Can we retain the following API classes please, marked as deprecated, but not for
> We have our own implementation of Activation, that we register with the RMI Registry.
> Removing these classes will cause many breakages and incompatibilities, we don't
> need the implementation of Activation.
> Apache River also uses these and has it's own implementation of Activation called
> The following interfaces:
> The following Exceptions:
> The following classes:
More information about the jdk-dev