[External] : Re: New candidate JEP: 407: Remove RMI Activation
stuart.marks at oracle.com
Tue May 4 23:05:11 UTC 2021
I'm not in charge of the namespace rules, and I can't change them.
Note that the entire Java EE ecosystem was transferred into a different namespace
under Jakarta EE, and they've kept moving forward, so the namespace issue is not at
My point about the support for RMI Activation inside the RMI internals is that it
complicates the story. We can't just "leave the APIs in but remove the
implementation" because some of the implementation requires support from the RMI
internals won't there. Maybe there's a way for some kind of "external" activation to
work around the lack of this support; I don't know.
On 5/4/21 3:28 PM, Peter Firmstone wrote:
> Thanks Alan,
> That's basically it in a nutshell, API we depend on is being remove that we have no
> way of replacing, our software is of course maintained, current and fully functional.
> We just need permission to do load these classes ourselves and make our own library
> using the java.* namespace, change the rule please.
> On 5/05/2021 6:33 am, Alan Snyder wrote:
>> I know nothing about RMI Activation, but am curious about the general issue being
>> 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
>> 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.
>>> 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.
>>> 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
>>>> 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:
>>>> The following Exceptions:
>>>> The following classes:
More information about the jdk-dev