Disable the Java Management eXtension (JMX) “M-Let” feature by default, and deprecate for removal in a future release. Originally inspired by applets, M-Lets are irrelevant for modern applications. The remote class loading of M-Lets has been disabled by default since Java 6. The degradation and deprecation of this feature and the javax.management.loading API will have no impact on JMX, the JMX agent used for local and remote monitoring, the built-in instrumentation of the Java virtual machine, or tooling that uses JMX.
The Java Platform emphasises observability, monitoring, and management. It defines many APIs and provides several tools for observing, monitoring and managing applications. It includes built-in instrumentation of the Java virtual machine using the Java Management eXtension (JMX) architecture. It includes a JMX agent for both local and remote monitoring.
Instrumentation of resources is provided by one or more Managed Beans (MBeans). These Java objects provide the instrumentation of managed resources in a standardized way, to be manageable by a JMX agent.
The M-Let feature was defined by the Java Management Extensions Instrumentation and Agent Specification v1.0, in 2000, and was initially available in the JMX Reference Implementation. JMX, including the M-Let feature, was added to the Java Platform in 5 (2004).
Inspired by applets, which are now obsolete and deprecated for removal by JEP 398, the M-Let feature permits remotely loading and registering MBeans not known when the MBean server started. These MBeans are specified in a file (given by a URL), or programmatically, and may be local or remote code. There is no evidence that M-Lets were ever widely used (including that no new bugs have been logged and no forum discussion or other wider activity is detectable).
M-Lets involve the loading of MBeans and remote code with potentially malicious intent. For this reason, the feature has been disabled by default since Java 6 (2006). The feature can still be used but only when running with a Security Manager enabled. The Security Manager is a security feature that set out in early JDK releases to protect against the threat of malicious intent, but is now a legacy feature. The Security Manager cannot address, for example, most of the issues identified in the 2020 Common Weakness Enumeration Top 25 Most Dangerous Software Weaknesses, and was deprecated for removal in Java 17 by JEP 411. The M-Let feature will cease to be usable once the Security Manager is further degraded and eventually removed.
There is no significant interest in developing modern applications that use M-Lets. To move the Java Platform forward, we will disable by default, and deprecate the M-Let feature for removal. The disabling and deprecation will have no impact on users of JMX, the built-in instrumentation or any of the observability tools.
The API for M-Lets is the class
javax.management.loading.MLet and a number of related classes in the
To disable M-Lets by default, the class
javax.management.loading.MLet will throw UnsupportedOperationException from its preRegister method, unless the System Property com.sun.jmx.enableMLetRegistration is set to "true".
We will terminally deprecate the following 4 classes, by annotating them with
javax.management.loading.MLet-- Main M-Let definition.
javax.management.loading.MLetContent-- Represents the contents of the MLET tag.
javax.management.loading.PrivateMLet-- An MLet which is not added to the ClassLoaderRepository.
javax.management.loading.MLetMBean-- Management interface of the M-Let MBean.
javax.management.loading.ClassLoaderRepository is not being deprecated at this time, as there is potentially wider usage in servers that support multiple applications. It may be revisited in the future.
There are no realistic alternatives to removal.
Implementing new mechanisms to make M-Let usage safe, effectively making remote code trustworthy, is not realistic given that it requires a huge effort, there is little expectation of success, and no evidence of a demand.
Keeping the feature, even optionally and with warnings, could create a false sense of security.