New candidate JEP: 407: Remove RMI Activation

Stuart Marks stuart.marks at
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 
> removal?
> 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 
> Phoenix.
> The following interfaces:
> java.rmi.activation.ActivationInstantiator;
> java.rmi.activation.ActivationMonitor;
> java.rmi.activation.ActivationSystem;
> java.rmi.activation.Activator;
> The following Exceptions:
> java.rmi.activation.ActivateFailedException;
> java.rmi.activation.ActivationException;
> java.rmi.activation.UnknownObjectException;
> java.rmi.activation.ActivationException;
> java.rmi.activation.UnknownGroupException;
> The following classes:
> java.rmi.activation.ActivationID;
> java.rmi.activation.ActivationGroupDesc;
> java.rmi.activation.ActivationGroupDesc.CommandEnvironment;
> java.rmi.activation.ActivationGroupID;
> java.rmi.activation.ActivationDesc;

More information about the jdk-dev mailing list