In #20241, it's noted that `ClassFile.verify` can return a mix-and-match of mutable and immutable lists.
Though the mutability of the list returned by `verify` has no particular importance, as the mutable list is constructed on every call and does not mutate the models, there are a few scenarios that they matter. Since ClassFile API is designed with immutability in mind, we should change all lists in ClassFile API to be immutable. Change summary: - Critical scenarios where ClassFile API stores mutable objects: - `ClassSignature.typeParameters` - keeps user mutable list - `CompoundElement.elementList` - buffered models expose the underlying mutable list - `RuntimeInvisibleParameterAnnotationsAttribute`(and Visible) - keeps users' nest mutable lists in an immutable list - `StackMapFrameInfo.locals/stack` - keeps user mutable lists - Optional scenarios to return immutable for good practice - `ClassFile.verify` - mutable for full verified results - `CompoundElement.elementList` - safe mutable for bound models - Fail fast on user null `Attribute`s in `BoundAttribute.readAttributes` to prevent unmodifiable list containing null I have also checked if we should stick with null-hostile `List.of` lists instead of `Collections.unmodifiableList` lists; we are using `unmodifiableList` (extensively in Signature parsing, for example) or other ad-hoc immutable lists, so it is somewhat impractical and not meaningful to enforce null-hostility. (See the list in JBS) These use sites are too sporadic so I made no unit tests. ------------- Commit messages: - 8336032: Enforce immutability of Lists used by ClassFile API Changes: https://git.openjdk.org/jdk/pull/20380/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20380&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8336032 Stats: 30 lines in 11 files changed: 17 ins; 1 del; 12 mod Patch: https://git.openjdk.org/jdk/pull/20380.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20380/head:pull/20380 PR: https://git.openjdk.org/jdk/pull/20380
