JDK-8359917 : AttributeList, RoleList and UnresolvedRoleList should never accept other types of Object
  • Type: CSR
  • Component: core-svc
  • Sub-Component: javax.management
  • Priority: P4
  • Status: Closed
  • Resolution: Approved
  • Fix Versions: 26
  • Submitted: 2025-06-18
  • Updated: 2025-07-08
  • Resolved: 2025-07-08
Related Reports
CSR :  
Description
Summary
-------

The classes `javax.management.AttributeList`, and `javax.management.relation.RoleList` and `UnresolvedRoleList`, have a historical feature where they accept objects of the wrong type, and only check for wrong objects when (and after) the "asList()" method is called.  This feature should be removed, and these classes should never accept the wrong kind of Object.

Problem
-------

These three classes have unnecessary complexity around type-checking 
Objects which are added.  There is no need for these classes to hold Objects of the wrong type.

This feature was added between JDK1.5 and JDK1.6, for compatibility.   The compatibility issue was only ever minor: prior JMX releases 1.2 and 1.3 and the release in JDK 1.5 had methods which accepted the specific class.  Therefore even in JDK1.6, there was no expectation that these classes could hold anything other than the specific type.

Adding alien Objects has been specifically strongly discouraged in the AttributeList API docs, and should now be illegal, and the unnecessary complexity removed.

Solution
--------



Simply enforce the checking of types in these classes.  Fail fast, in the obscure case that incorrect types are used.




Specification
-------------

API changes:  API doc text updates.  No disruptive or incompatible API changes.

* In the class AttributeList:

Remove the text:
```
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.
```

Replace with:

```
 * <p>It is not permitted to add objects to an {@code AttributeList} that are
 * not instances of {@code Attribute}.  This will produce an {@code IllegalArgumentException}
 * when calling methods in this class, or when using {@code listIterator} and {@code add} or {@code set}.</p>
```

In the "asList()" method, remove:
"If this method has ever been called on a given AttributeList instance, a subsequent attempt to add an object to that instance which is not an Attribute will fail with an IllegalArgumentException. For compatibility reasons, an AttributeList on which this method has never been called does allow objects other than Attributes to be added."

Update the wording of some throws messages for IllegalArgumentException.


* In the class javax.management.relation.RoleList:

Similarly to AttributeList, add: 

```
 * <p>It is not permitted to add objects to a {@code RoleList} that are
 * not instances of {@code Role}.  This will produce an {@code IllegalArgumentException}
 * when calling methods in this class, or when using {@code listIterator} and {@code add} or {@code set}.</p>
```

Remove the same wording from the "asList()" method.

Updatewording of some throws messages for IllegalArgumentException.

Add inheritdoc tags for clarity.


* In the class javax.management.relation.RoleUnresolvedList

Similarly to AttributeList, add: 

```
 * <p>It is not permitted to add objects to a {@code RoleUnresolvedList} that are
 * not instances of {@code RoleUnresolved}.  This will produce an {@code IllegalArgumentException}
 * when calling methods in this class, or when using {@code listIterator} and {@code add} or {@code set}.</p>
```

Remove the same wording from the "asList()" method.

Change wording of some throws messages for IllegalArgumentException.

Add inheritdoc tags for clarity.


In the attached specdiff_8359809.zip file, see:

AttributeList.html

relation/RoleList.html

relation/RoleUnresolvedList.html



Github reference: https://github.com/openjdk/jdk/pull/25856
Comments
Moving updated request to Approved.
08-07-2025

Updated including updated comment about listIterator. Attached a new specdiff zip file.
01-07-2025

> Without an override of the listIterator method I believe the current classes have a latent bug as the backing list can be mutated via the iterators set() or add() methods. In other words, for correctness the typing checks need to be added to the iterator returned by the listIterator method of these stand-alone "checked" lists. HTH Thanks [~darcy], yes sure. I'd like to press ahead with this change to remove possible pollution of these list classes with foreign types, using the established methods, and its strange historic special case behaviour before/after an asList() call. I logged JDK-8361088 to follow up, as would like to update iterator behaviour separately. This is not the established usage of these classes, but should be updated.
30-06-2025

> > do these classes properly override the set and add methods of iterator > > returned by the listIterator method? > > No, these classes have no specific mention of Iterator. This change is > just about keeping out the wrong kind of members. If we see any > problems about iterator behaviour we can handle that separately. Without an override of the listIterator method I believe the current classes have a latent bug as the backing list can be mutated via the iterators `set()` or `add()` methods. In other words, for correctness the typing checks need to be added to the iterator returned by the listIterator method of these stand-alone "checked" lists. HTH
25-06-2025

> do these classes properly override the set and add methods of iterator returned by the listIterator method? No, these classes have no specific mention of Iterator. This change is just about keeping out the wrong kind of members. If we see any problems about iterator behaviour we can handle that separately. > do any of the other "Methods inherited from ArrayList add, add, addAll, addAll, addFirst, addLast" also need overrides or updates to accommodate the exception being thrown? Yes there are api doc additions for the overridden methods that take Object or Collection, and not for the non-overridden add methods that take a specific type (they don't check the type and throw). e.g. the overridden method, public boolean add(Object o) which now checks type, documents the possible exception. But public void add(Role role) only takes a Role, and does not specifically check the type, or throw an exception. Now I notice this method does not override addFirst and addLast, becuase they are new in 21, and none of the (our!) code that uses AttributeList or Role*List uses them. We could consider overriding them.
25-06-2025

PS [~kevinw], do these classes properly override the set and add methods of iterator returned by the listIterator method? See as a comparison the CheckedList implementation in java.util.Collections. HTH
24-06-2025

Moving to Provisional, not Approved. Hmm. [~kevinw], do any of the other "Methods inherited from ArrayList add, add, addAll, addAll, addFirst, addLast" also need overrides or updates to accommodate the exception being thrown?
24-06-2025

This looks okay.
20-06-2025