Summary

Remove the Java Management Extension (JMX) Management Applet (m-let) feature. M-lets, which were inspired by applets, are irrelevant to modern applications. This removal 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.

Problem

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 remove the feature. This removal will have no impact on users of other JMX features, the JDK’s built-in instrumentation, or any of the observability tools.

m-lets are referenced in:

• JSR 22: JAIN SLEE API Specification 1.0 (1999-2004) https://download.oracle.com/otndocs/jcp/jain_slee-1_0-fr-spec-oth-JSpec/

• JSR 240: JAIN SLEE (JSLEE) v1.1 (2004-2008) https://download.oracle.com/otndocs/jcp/jain_slee-1_1-final-eval-oth-JSpec/

In both, it is stated that use of javax.management.loading.MLet is not absolutely required. In v1.1, Section 14.4.1:

"the javax.management.loading.MLet MBean can be used by a SLEE implementation to perform parsing of a MLet text file and instantiation of the MBeans defined in it, however this method of loading MLet MBeans is not prescriptive."

The known implementation, Rhino Telecom Application Server, has its own m-let implementation, not dependent on javax.management.loading.MLet.

Our corpus search finds references to MLet classes which are mainly explained by:

• MX4J was an open JMX implementation, which contains its own MLet implementation classes. This dependcency is bundled in many projects, but it is no longer maintained. Depending on or including MX4J is not a dependency on MLet classes in the JDK.
• Tomcat 7 (EOL) recognised m-lets but that is gone in Tomcat 8.
• Jakarta/Apache Commons Modeler for JMX interacted with m-lets. Last release was in 2007.
• Sun Java System Message Queue 4.3 (2008) referenced the MLet class.
• JBoss in past versions had its own m-let implementation, as did Milyn J2EE (2006).

For one additional project built in 2021 for JDK6, with reference to MLets, an Issue has been raised to notify of this removal (OpenTSDB).

Solution

Remove the feature.

Deprecation for removal was initially written up as a JEP and comments were invited in email: https://mail.openjdk.org/pipermail/jmx-dev/2022-July/001806.html

The JEP was agreed to be unnecessary, and the deprecation for removal was progressed in a JBS Enhancement and CSR. This was reviewed in the open: https://mail.openjdk.org/pipermail/jmx-dev/2022-November/002009.html

No comments were made on the draft JEP, and only procedural discussion happened on the review thread. No objections or problems were mentioned, no impact of the change was raised.

There are options around degradation rather than immediate removal which have been considered, but they are not expected to offer any real benefits. For example:

• Removing Java code content of the deprecated classes, or their constructors, and always throwing an Exception: this keeps the classes present for compilation (with existing deprecation warnings) and so prolongs source compatibility. Binary compatibility is somewhat maintained, in that programs will execute to a limited degree.

• A disabled-by-default option could be considered, where the feature fails with an Exception if an enabling property is not set. This maintains compatibility and adds an extra level of warning regarding removal.

The m-let feature is not believed to have wide enough usage to make the complexity and the delay to eventual removal worthwhile. If there is a user of this feature on a modern JDK, they are already seeing the Security Manager warnings. If code is rebuilt on a modern JDK the classes will trigger deprecation warnings.

The javax.management.loading package will still contain ClassLoaderRepository, used for managing ClassLoaders in an MBean Server. This is not affected by the removal of m-lets.

Specification

Remove the public API:

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

Remove tests.

Draft github PR: https://github.com/openjdk/jdk/pull/16363

There are non-MLet-specific tests which use MLet, which need some work to make the PR final.