jvisualvm MBeans plugin can't display complex data type

1. Problem

jvisualvm MBeans plugin can't display complex data type, as shown below:

2. Analysis

Quoted from Reference [1]:

Complex data types
It is often necessary or desirable for these data types to be more complex than simple Java types such as int or String. In particular, when an attribute represents a snapshot of values such as the state of a thread at a given moment, it may not be meaningful to see a set of different values taken at different times. That could lead to meaningless results such as a thread that appears to be both running and waiting for a certain lock.

Using multiple attributes instead of complex data types
It is sometimes possible to address situations like this by breaking out the set of values into separate attributes and stipulating that those attributes must be read or written with a single getAttributes or setAttributes operation. But this tends to be a special-case solution that is difficult to implement and error-prone when clients fail to respect the requirement for using a single operation. It is also fragile in the face of evolution of the model. For example it does not extend to operation parameters or return values, and it does not work well if the values broken out into attributes are themselves complex types. So in general it is better to have a single data type representing the atomic set of values.

Using model-specific classes for complex data types
Complex data types can also be represented by defining model-specific types, for example a ThreadInfo type for a snapshot of a thread. But this solution presents its own problems. Chief among these is that the client must have the same Java classes available. This is very inconvenient for model-neutral clients such as generic JMX consoles. It also potentially causes problems for access from languages other than Java (for instance, from scripts). And it can lead to serious class-loading headaches if the same client must interact with servers that have different versions of the model-specific classes. Finally, using arbitrary Java types can lead to unforeseen problems with serialization, since when an object is serialized other objects that it references may also be serialized, meaning that a client must have the classes for those other objects available too.

Reference

[1] http://www.oracle.com/technetwork/java/javase/tech/best-practices-jsp-136021.html?ssSourceSiteId=ocomen#mozTocId931827