Currently, the Zabbix Java Gateway supports the key "jmx.discovery" which will list the meta data about all the MBeans registered on the remote Java server. This isn't really practical though to use for low level discovery because different items will have different data types and different collection intervals based on what the data is etc. I'm proposing adding new jmx.discovery key that will allow querying of MBeans given a wildcard format. So for instance the format would be:

jmx.discovery[<ObjectNameWildcard>]

I have a custom Zabbix Java Gateway project that has this commit here: https://bitbucket.org/ryanrupp/zabbix-java-gateway/commits/d67451dcee677974bea37b6369cfadf08eb1b988
I plan on cleaning up that and providing a patch for this Jira.

Here's a writeup I have for this feature:

New Discovery Options
Before utilizing this you should understand how Zabbix low level discovery works, this is documented here

A new JMX discovery option has been added to both the standard Zabbix JMX checker and Jolokia checker. This discovery option allows you to search for specific MBeans by using a wildcard in the ObjectName. The format is as follows:

jmx.discovery[<ObjectNameWildcard>]
This helps solve issues such as dynamically named MBeans for both the Memory Pool and Garbage Collectors as their names may vary depending on the JVM or arguments passed to the Java process. Here's an example using the Memory Pool MBeans, for my particular JVM I have the following MBeans for the Memory Pool:

java.lang:type=MemoryPool,name=CMS Old Gen
java.lang:type=MemoryPool,name=CMS Perm Gen
These are prefixed with "CMS" due to the use of Concurrent Mark Sweep on my particular JVM - this will vary depending on the garbage collector used, for instance if the Parallel Scavenge Collector is being used the MBean name would be "PS Old Gen". Now, to resolve this with the new discovery feature you create a Zabbix Discovery item with the following item definition (JMX item):

jmx.discovery["java.lang:type=MemoryPool,name=*"]
You'll notice the name isn't specified but rather a wildcard here. This means return all MBeans whose object names match the beginning section (Memory Pool) but retrieve any "name" value. The Zabbix Java Gateway will then respond with this using the Zabbix discovery format:

{
"data": [
{
"

{#NAME}": "CMS Old Gen",
"{#JMXOBJ}": "java.lang:name=CMS Old Gen,type=MemoryPool",
"{#TYPE}": "MemoryPool"
},
{
"{#NAME}

": "CMS Perm Gen",
"

{#JMXOBJ}": "java.lang:name=CMS Perm Gen,type=MemoryPool",
"{#TYPE}": "MemoryPool"
}
]
}
The macro {#JMXOBJ}

is returned for each matching MBean found, this is the full name of the MBean that was found and can be used then in Zabbix prototype items via Zabbix Discovery. Additionally, for each property in the MBean's ObjectName a macro is returned. So, in this example there were two properties in the ObjectName - Type and Name, the Type being MemoryPool and the Name being whichever Memory Pool it was. These can also be used in your Zabbix prototype definitions. For instance I could make a prototype item with the item name:

{#NAME}

Memory Used
The Zabbix discovery process in the previous example would then result in two items:

CMS Old Gen Memory Used
CMS Perm Gen Memory Used