RFR: 8294982: Implementation of Classfile API [v41]

[Jaikiran Pai]

On Fri, 3 Mar 2023 13:50:15 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:
> 
>   Signature.TypeArg does not inherit from Signature

src/java.base/share/classes/jdk/internal/classfile/AccessFlags.java line 54:

> 52:      * {@return whether the specified flag is present}  The specified flag
> 53:      * should be a valid flag for the classfile location associated with this
> 54:      * element.

Hello Adam, the way this is worded, it feels like if the flag isn't valid then this method would raise an exception. Looking at the implementation, that doesn't look like the case. Should it be reworded to say it returns false in such cases?

On a related note, since this JEP is for introducing this API for internal use only, would you prefer if the javadoc text isn't reviewed to this level of detail?

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

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