In javax.management.modelmbean.DescriptorSupport, the specification for the (String) constructor and the toXMLString() method explicitly says that you should be able to take a string produced by the latter and give it to the former to get a DescriptorSupport that is equivalent to the original. That is, you should be able to do this:
    DescriptorSupport ds1 = ...;
    String xml = ds1.toXMLString();
    DescriptorSupport ds2 = new DescriptorSupport(xml);
...and have ds2 be "equivalent" to ds1.

However, for fields that have values that are not strings, this requirement is clearly violated. If a field has a null value, the resultant XML is exactly the same as for a field with the string value "null". If a field has a non-null, non-String value, the resultant XML contains "(" + value.toString() + ")", but the constructor treats this the same as any other value. So the reconstructed DescriptorSupport has obtained an extra pair of parentheses from nowhere. Even though the spec doesn't explicitly say what it means for two DescriptorSupport objects to be "equivalent", it is pretty clear that adding these parentheses precludes equivalence.

Example:
    DescriptorSupport ds1 =
        new DescriptorSupport(new String[] {"blah"},
                              new Object[] {Boolean.TRUE});
    String xml = ds1.toXMLString();
    DescriptorSupport ds2 = new DescriptorSupport(ds1);

ds1.getFieldValue("blah") is Boolean.TRUE, a java.lang.Boolean.
ds2.getFieldValue("blah") is the string "(true)". If it were the string "true" we could argue that the descriptors were equivalent.
Note that the toString() for the two descriptors is indeed the same.