JEP draft: Deprecate JMX Management Applets for Removal

This JEP was withdrawn, and deprecation for removal was implemented with an Enhancement Request and the CSR process. A JEP was agreed to be unnecessary.

Summary

Deprecate the Java Management Extension (JMX) Management Applet (m-let) feature for removal in a future release. M-lets, which were inspired by applets, are irrelevant to modern applications. The deprecation of this feature will have no impact on the JMX agent used for local and remote monitoring, the built-in instrumentation of the Java virtual machine, or tooling that uses JMX.

Motivation

The Java Platform and the JDK define many APIs and provide several tools for observing, monitoring, and managing applications. Among these are the Java Management Extensions (JMX), which include an agent for both local and remote monitoring by management applications. Instrumentation of specific resources is provided by one or more Managed Beans (MBeans). These Java objects provide instrumentation of managed resources in a standardized way, and a JMX agent can expose this instrumentation to monitoring and management tools.

The m-let feature was defined in the first version of the Java Management Extensions Specification (2000) and was initially available in the JMX Reference Implementation. JMX, including the m-let feature, was integrated into the Java Platform in Java 5 (2004). Inspired by applets, which are now obsolete and deprecated for removal (JEP 398), the m-let feature permits the remote loading and registration of MBeans not known when the MBean server started. The code for these MBeans can be either local or remote.

The m-let feature can load remote code with potentially malicious intent. For this reason, some dynamic loading features are restricted. Specifically, the addURL and getMBeansFromURL methods cannot be invoked without a Security Manager. The Security Manager is a security feature that set out in early JDK releases to protect against the threat of malicious code, but is now a legacy feature. The Security Manager cannot address, for example, most of the issues identified in the 2020 CWE Top 25 Most Dangerous Software Weaknesses, and was deprecated for removal in Java 17 by JEP 411. The dynamic loading features of m-lets mentioned above will cease to be usable once the Security Manager is further degraded and eventually removed.

There is no evidence that m-lets were ever widely used: There are no bug reports, and no evidence of discussion in public forums. There is no significant interest in developing modern applications that use m-lets. To move the Java Platform forward, we will deprecate the m-let feature for removal. This deprecation will have no impact on users of other JMX features, the JDK’s built-in instrumentation, or any of the observability tools.

Description

We will terminally deprecate the following classes, by annotating them with @Deprecated(forRemoval=true):

• javax.management.loading.MLet
• javax.management.loading.MLetContent
• javax.management.loading.PrivateMLet
• javax.management.loading.MLetMBean

We will not deprecate the javax.management.loading.ClassLoaderRepository class at this time, since it may be useful to application servers running several applications in the same Java virtual machine. We may revisit this in the future.

Alternatives

• Do nothing. Some dynamic loading features of m-lets will cease to be usable once the Security Manager is degraded or removed, so this is not a feasible option.

• Design a new API and means to securely load and register MBean classes from remote locations at run time. As stated, there is no significant interest in developing modern applications that use m-lets, so this alternative is not worth pursuing.