JDK-6405862 : Allow CompositeType to have zero items
  • Type: Enhancement
  • Component: core-svc
  • Sub-Component: javax.management
  • Affected Version: 6
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2006-03-29
  • Updated: 2017-05-16
  • Resolved: 2011-03-08
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 7
7 b36Fixed
Related Reports
Relates :  
JDK-5072004 - Better support for schema evolution in CompositeData and CompositeType
Relates :  
JDK-6747770 - TEST : test/javax/management/mxbean/CustomTypeTest.java missing @bug 6405862
Relates :  
JDK-6752563 - Allow CompositeDataSupport to have zero items
Description
A javax.management.openmbean.CompositeType defines a list of items, where each item has a name and a type.  The specification currently disallows a CompositeType with an empty list of items.  With the implementation of 5072004, which allows a CompositeData to contain additional items and still be compatible with a CompositeType, it is now meaningful to have an empty CompositeType.  This simply means that the corresponding CompositeData instances will have only additional items, and no fixed items.  In particular this can be used to handle "any"-type values in MXBeans.
Comments
EVALUATION The preceding comment is incorrect. 5072004 was implemented in Java SE 6 but the implementation of this RFE was only integrated in b30 of JDK 7. Because this spec change was not in fact part of the 5072004 spec change, a new CCC request is needed to cover this change.
08-07-2008
EVALUATION This was fixed as part of the fix for 5072004.
14-11-2006
EVALUATION It is unlikely that any existing code would be broken if we simply removed the clause "should contain at least one element" from the @param itemNames of the CompositeType constructor and changed the implementation accordingly. (The implementation currently reads this "should" as a "must".)
29-03-2006