The methods invoke and createMBean have a signature parameter, which is an array of Java class names (as returned by Class.getName()). These allow the MBean Server to determine which method or constructor to invoke in case of overloading. In the case of createMBean, the signature can be omitted, but only if there are no constructor parameters.

It's extremely tedious to supply this array, given that it is almost never necessary, since there is almost never overloading. In the case of invoke, the problem is not too severe since usually the invoke happens via a proxy, which will compute the correct signature array. But in the case of createMBean, there is no similar convenience, and if there are any constructor parameters then you must supply a signature array.

The proposed change is to allow the signature to be null. In that case there must be exactly one public method of the given name (for invoke) or constructor (for createMBean) that matches the number and types of the parameters. Otherwise an exception is thrown.

The existing implementation already allows the signature to be null and treats it as an empty array. But this is only valid today if the params array is also null or empty. So there is no change to the semantics for successful invoke or createMBean calls with a null signature array.

Existing Dynamic MBeans will probably not contain the logic in their invoke methods to handle a null signature. Therefore they will not be invokable in this way. There is no similar problem for constructors, which as noted above is the more important case for this functionality.