RFR: 8336032: Enforce immutability of Lists used by ClassFile API

[Adam Sotona]

On Mon, 29 Jul 2024 19:36:31 GMT, Chen Liang <liach at openjdk.org> wrote:

> 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.

Nice cleanup, thank you.

-------------

Marked as reviewed by asotona (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20380#pullrequestreview-2207025233