New candidate JEP: 407: Remove RMI Activation

[Alan Snyder]

I know nothing about RMI Activation, but am curious about the general issue being raised.

I understand the issue to be allowing application code that use these classes to continue to work using the third party implementations that they currently use.

What would be the implications of moving this chunk of code into a separate library that could be managed by a third party?

I can think of one obstacle, which is the rule that prevents third party code from defining symbols in the “java.*” package name space. Could an exception be carved out?

Technically, does the implementation of RMI Activation require (versus “currently use”) private services of the JDK? The request implies that it does not. Your answer implies that it does.

  Alan






> On May 4, 2021, at 12:55 PM, Stuart Marks <stuart.marks at oracle.com> wrote:
> 
> 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 unchanged.
> 
> - 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.
> 
> s'marks
> 
> 
> 
> 
> 
> 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;
>