The resource at the addresses above is really just a placeholder; the
actual mbeans are exposed via child resources. The names of the child
resources follow a pattern based on the ObjectName of the underlying mbean:
/core-service=platform-mbean/type=memory-pool/name=<escaped pool name>
The "type" and "name" child types match the keys in the standard
platform mbean ObjectName properties. The values for the 'type'
attribute are the same as the ObjectName values, but converted to match
standard domain management API resource name standards:
1) All lower case
2) A '-' used to separate words where the ObjectName preoperty value
would use CamelCase.
The value of the "name" property in a platform mbean depends on the
runtime platform; it is not known in advance. I did not attempt to
convert this portion of the platform mbean names to lower-case with '-'
separator convention. The <escaped pool name> above refers to the fact
that the ObjectName for some mbeans may includes spaces in the value of
the "name" key. Spaces are not valid in resource addresses, so any
spaces have been replaced with the '_' character in the address.
See  for the full list of resource names.
Note that the attributes and metrics exposed by these resources are
"runtime" attributes; i.e. they are not directly stored in any
persistent configuration. The handlers for the standard "read-resource"
and "read-children-resources" operations will not include "runtime"
attributes in a result unless parameter "include-runtime" is provided
with value 'true'. So be sure to include that parameter when trying to
read these resources, or you will be a successful but receive an empty
The MBean attributes of the platform mbeans are exposed as resource
attributes. The operations are exposed as operations with the same
parameters. The attribute, operation and parameter names are the same as
what is found in the JDK javadoc for the relevant mbean, except the
CamelCase to lower-case with '-' separator conversion is followed
The only place where an attribute, operation or parameter name should
vary from the JDK name is with the ThreadMXBean's getThreadInfo method.
Some overloaded variants of that method return an array, some a single
value. The domain management API does not support multiple return value
types from an operation with the same name. So, the operation for the
overloaded variants that return a single value is 'get-thread-info'
while for the variants the return multiple values the operation is