Fix the MBean design flaw by defining MXBean that allows the interface
to use basic types, "struct-like" Java types, enums, List, Map, and Set.

The applications and JRE would only need to use MXBeans or standard
MBeans which are so simple to use and implement and move away
from overly complex open mbeans. This would set up a good and
effective guideline for JMX community as well as Sun internally
including J2EE and J2SE.

For java.lang.management API in 1.5, this proposal (see below)
will define the basic (minimal) requirements for MXBean to address
the interoperation issue. This will guarantee that MXBeans defined
in J2SE 1.5 will be compatible with the standard MXBean the JMX
community defines for the next J2SE release (JMX spec lead will
work with the JMX community on this).

PROBLEM:
========
The current java.lang.management API are restricted to use basic types and
JMX CompositeData and TabularData for interoperation due to the limitation
of JMX MBean. JMX OpenMBeans are supposingly designed for interoperation
but it has various usability issues.

In addition, J2EE 1.4 depends on JMX 1.2 and requires no API change to JMX 1.2 in J2SE 1.5.

The drawbacks of the current MBean designs:
- Hard and tedious to use and a more complex specification of the interface
- Need to read the specification carefully to find out the names and types of the attributes in the CompositeData
- Need to cast an attribute value to the right type
- Static factory "from" method converting from CompositeData to the Java type helps the local access and remote proxy access but not all types have the "from" method (for example, List, Map and the API are forced to use n-dimensional arrays or the "complicated" TabularData).
- Lost compile-time type-checking
- Future JRE MBeans may easily overlook the interoperation issue and design
MBeans to use regular Java types which are not interoperable. Based on the complexity we felt that we would have a hard time convincing JMX users (both within Sun and outside) to restrict the types are used in the definition of a MBean interface so as to get inter operation across versions and also potentially across programming languages.


SOLUTION:
========
1. Define MXBean as the management interface. MXBean is very similar to MBean
and they are guaranteed to be interoperable.

The MXBean must only reference basic types, enums, "struct-like" Java types (only getters), List, Map, and Set.

These types are mapped to simple types, CompositeData, or TabularData
when the MXBeans are accessed via MBeanServer.

2. Rename java.lang.management MBeans to MXBeans.

ClassLoadingMBean -> ClassLoadingMXBean
CompilationMBean -> CompilationMXBean
GarbageCollectorMBean -> GarbageCollectorMXBean
MemoryMBean -> MemoryMXBean
MemoryManagerMBean -> MemoryManagerMXBean
MemoryPoolMBean -> MemoryPoolMXBean
OperatingSystemMBean -> OperatingSystemMXBean
RuntimeMBean -> RuntimeMXBean
ThreadMBean -> ThreadMXBean

3. Rename the suffix of the following methods in ManagementFactory
class from MBean to MXBean

    public static ClassLoadingMBean getClassLoadingMBean()
    public static MemoryMBean getMemoryMBean()
    public static ThreadMBean getThreadMBean()
    public static RuntimeMBean getRuntimeMBean()
    public static CompilationMBean getCompilationMBean()
    public static OperatingSystemMBean getOperatingSystemMBean()
    public static java.util.List getMemoryPoolMBeans()
    public static java.util.List getMemoryManagerMBeans()
    public static java.util.List getGarbageCollectorMBeans()
    public static synchronized MBeanServer getPlatformMBeanServer()

4. Add a new method to return a MXBean proxy.
   public static <T> T makeProxy(MBeanServerConnection mbsc,
                                  ObjectName objectName,
                                  Class<T> mxbeanInterface)

5. The return types are changed to return the Java type (MemoryUsage, ThreadInfo, MemoryType).

The return type of the following methods will be changed to MemoryUsage:

MemoryPoolMBean.java: public CompositeData getUsage();
MemoryPoolMBean.java: public CompositeData getPeakUsage();
MemoryPoolMBean.java: public CompositeData getCollectionUsage();

The return type of the following methods will be changed to ThreadInfo / ThreadInfo[]:
ThreadMBean.java: public CompositeData getThreadInfo(long id);
ThreadMBean.java: public CompositeData[] getThreadInfo(long[] ids);
ThreadMBean.java: public CompositeData getThreadInfo(long id, int maxDepth);
ThreadMBean.java: public CompositeData[] getThreadInfo(long[] ids, int maxDep

The return type of the following method will be changed to MemoryType:
MemoryPoolMBean.java: public String getType();

6. Change the following to return List<String> instead of String[]
  MemoryManagerMBean.getMemoryPoolNames()
  MemoryPoolMBean.getMemoryManagerNames()
  RuntimeMBean.getInputArguments()

IMPACT
======
NSK and JCK tests will be impacted by this spec change.
Two major pieces of work for updating the tests per this spec change are:
1) Rename MBean to MXBean.

A sed script can be easily written to update all tests for this name change.

2) Return type change in 8 methods listed in (5) above

Most of the impacted tests are written to operate on MemoryUsage and
ThreadInfo converted from the returned CompositeData by calling from method.
The changes should be very minimal by just removing the call to MemoryUsage.from method and ThreadInfo.from method.

Tests that operate on CompositeData verify the returned CompositeData
attributes are required to be updated to use MBeanServer API instead
of MXBeans. These types are mapped to CompositeData same as what the
current MBean interface defines when you invoke the method via the
MBeanServer. For example, MemoryPoolMXBean.getUsage() returns MemoryUsage
object. If you get "Usage" attribute from this bean in the MBeanServer,
you will get CompositeData.
   CompositeData cd = (CompositeData) mbs.getAttribute(poolObjName, "Usage");