JEP 385: Deprecate RMI Activation for RemovalJEP 385: Deprecate RMI Activation for RemovalOwnerStuart MarksTypeFeatureScopeSEStatusClosed / DeliveredRelease15Componentcore-libs / java.rmiDiscussioncore dash libs dash dev at openjdk dot java dot netEffortXSDurationXSRelates toJEP 407: Remove RMI ActivationReviewed byAlan Bateman, Roger RiggsEndorsed byBrian GoetzCreated2020/05/13 02:43Updated2021/08/28 00:23Issue8244917Summary
Deprecate the RMI Activation
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.
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
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
module specification.


Add a notice of deprecation to the
RMI Activation
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
tool to emit a warning message about deprecation.


Add warning notices to the
rmid tool documentation page.
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 project contains forked versions of RMI and
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.
InstallingContributingSponsoringDevelopers' GuideVulnerabilitiesJDK GA/EA BuildsMailing listsWiki
                      · IRCBylaws · CensusLegalWorkshopJEP ProcessSource codeMercurialGitHubToolsGitjtreg harnessGroups(overview)AdoptionBuildClient LibrariesCompatibility & Specification ReviewCompilerConformanceCore LibrariesGoverning BoardHotSpotIDE Tooling & SupportInternationalizationJMXMembersNetworkingPortersQualitySecurityServiceabilityVulnerabilityWebProjects(overview,
      archive)AmberBabylonCRaCCaciocavalloClosuresCode ToolsCoinCommon VM InterfaceCompiler GrammarDetroitDevelopers' GuideDevice I/ODukeGalahadGraalIcedTeaJDK 7JDK 8JDK 8 UpdatesJDK 9JDK
      (…,
       21,
       22,
       23)JDK UpdatesJavaDoc.NextJigsawKonaKullaLambdaLanaiLeydenLilliputLocale EnhancementLoomMemory Model UpdateMetropolisMission ControlMulti-Language VMNashornNew I/OOpenJFXPanamaPenrosePort: AArch32Port: AArch64Port: BSDPort: HaikuPort: Mac OS XPort: MIPSPort: MobilePort: PowerPC/AIXPort: RISC-VPort: s390xPortolaSCTPShenandoahSkaraSumatraTiered AttributionTsanType AnnotationsValhallaVeronaVisualVMWakefieldZeroZGC

        © 2024 Oracle Corporation and/or its affiliates
        Terms of Use
        ·
        
            License: GPLv2
        · Privacy
        · Trademarks
