RFR: 8294982: Implementation of Classfile API [v20]

[Jens Lidestrom]

On Thu, 16 Feb 2023 10:41:33 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> This is root pull request with Classfile API implementation, tests and benchmarks initial drop into JDK.
>> 
>> Following pull requests consolidating JDK class files parsing, generating, and transforming ([JDK-8294957](https://bugs.openjdk.org/browse/JDK-8294957)) will chain to this one.
>> 
>> Classfile API development is tracked at:
>> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-branch
>> 
>> Development branch of consolidated JDK class files parsing, generating, and transforming is at:
>> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-dev-branch
>> 
>> Classfile API [JEP](https://bugs.openjdk.org/browse/JDK-8280389) and [online API documentation](https://htmlpreview.github.io/?https://raw.githubusercontent.com/openjdk/jdk-sandbox/classfile-api-javadoc-branch/doc/classfile-api/javadoc/java.base/jdk/internal/classfile/package-summary.html) is also available.
>> 
>> Please take you time to review this non-trivial JDK addition.
>> 
>> Thank you,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added 4-byte Unicode text to Utf8EntryTest

src/java.base/share/classes/jdk/internal/classfile/constantpool/ConstantPoolBuilder.java line 96:

> 94:      * @param <T> the type of the option value
> 95:      */
> 96:     <T> T optionValue(Classfile.Option.Key option);

This unconstrained type parameter will result in and implicit conversion to any type that the caller assigns it to, which might result in a `ClassCastException` if the caller gets the type wrong.

Is that intentional?

Alternative solutions: 

* Convert `Key` to an ordinary class or sealed interface, and add a type parameter to it, for the value type.
* Add a parameter the the method of type `Class<T>`.

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

PR: https://git.openjdk.org/jdk/pull/10982