JEP draft: Deprecate JMX M-Lets (Management Applets) for Removal

OwnerKevin Walls
Componentcore-svc /
Discussionjmx dash dev at openjdk dot java dot net
Created2022/04/27 13:50
Updated2022/08/16 08:45


Deprecate the Java Management eXtension (JMX) “M-Let” feature 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 deprecation of this feature and the 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 documented in the Java Management Extensions Instrumentation and Agent Specification v1.0, in 2000, and was initially available in the JMX Reference Implementation. It was included when JMX was added to Java 5 in 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 deprecate the M-Let feature for removal. The deprecation will have no impact on users of JMX, the built-in instrumentation or any of the observability tools.


The M-Let technology consists of the API and several related APIs in the package.

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


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.