Recently asked on IRC.

The key jmx.discovery returns a json object including these macros (for all objects, not only the examples below!):

{"data": [
  {
    "{#JMXATTR}": "ImplementationVendor",
    "{#JMXDESC}": "the JMX implementation vendor (the vendor of this product).",
    "{#JMXOBJ}": "JMImplementation:type=MBeanServerDelegate",
    "{#JMXTYPE}": "java.lang.String",
    "{#JMXVALUE}": "Sun Microsystems"
  },
  {
    "{#JMXATTR}": "HeapMemoryUsage.init",
    "{#JMXDESC}": "java.lang:type=Memory,HeapMemoryUsage.init",
    "{#JMXOBJ}": "java.lang:type=Memory",
    "{#JMXTYPE}": "java.lang.Long",
    "{#JMXVALUE}": "47445376"
  }
]}

Since jmx.discovery returns all objects a proper filter within the discovery rule is needed for almost any scenario.

Example for discovering memory pools:
Filter macro:

Filter Regexp: ^java.lang:type=MemoryPool,

Anyhow, jmx.discovery with the current implementation of unique key constraint (see ZBXNEXT-1606) is practically useless.
Possibly that's the reason why it's not mentioned in the documentation yet.

Related issues that request improvement of jmx.discovery:

• ZBXNEXT-1223
• ZBXNEXT-1648

Item "jmx.discovery" in its current form was meant solely for development and testing purposes, and is not useful for general public, because it returns all the objects it can find. This is the reason it is not documented.

ZBXNEXT-1223 strives to improve the item to make it useful. We shall document the new functionality that will appear under that issue, so closing this issue as a duplicate.