These classes (derived from ArrayList), are permissive with what Objects they accept being added:

javax.management.AttributeList
javax.management.relation.RoleList
javax.management.relation.RoleUnresolvedList

javax.management.AttributeList states:

"For compatibility reasons, it is possible, though highly discouraged, to add objects to an AttributeList that are not instances of Attribute. However, an AttributeList can be made type-safe, which means that an attempt to add an object that is not an Attribute will produce an IllegalArgumentException. An AttributeList becomes type-safe when the method asList() is called on it."

It is documented that adding anything other than instances of Attribute is highly discouraged.

This should be extended such that non-null Objects which are not an Attribute are always refused.

RoleList and RoleUnresolvedList have the same comment in the asList() method, which should be removed with the behaviour.

We have always accepted nulls, changing that is most likely too much, i.e. it could be disruptive to start throwing Exceptions when an existing application adds a null Attribute to an AttributeList. But adding alien Objects has never been encouraged and should now be illegal, and the unnecessary complexity removed from AttributeList.


It is not clear what this is compatibility with. A much much earlier AttributeList implementation perhaps, but not the JMX 1.1 and 1.2 MR Spec which contained:

javax.management.AttributeList:

"Represents a list of values for attributes of an MBean. The methods used for the insertion of Attribute objects in the AttributeList overrides the corresponding methods in the superclass ArrayList. This is needed in order to insure that the objects contained in the AttributeList are only Attribute objects. This avoids getting an exception when retrieving elements from the AttributeList."

The add method was: public void add(Attribute object)
(not accepting Object)

i.e. those were more strict, with none of the conditionally "type-safe" wording of the JDK. The flexibility was added between JDK5 and JDK6, relating to generics and the existing inheritance arrangement. JDK-6250772 notes: "AttributeList, RoleList, and RoleUnresolvedList currently extend raw ArrayList rather than ArrayList<Attribute> etc, because of compatibility problems with method return types."