RFR: 8294982: Implementation of Classfile API
Adam Sotona
asotona at openjdk.org
Mon Nov 7 10:16:34 UTC 2022
On Fri, 4 Nov 2022 12:38:04 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/jdk/classfile/package-summary.html) is also available.
>
> Please take you time to review this non-trivial JDK addition.
>
> Thank you,
> Adam
This pull request (plus a set of planned "chained" pull requests) is an attempt to resolve chicken and egg situation in the Classfile API development.
According to the JEP summary will Classfile API initially serve as an internal replacement for ASM in the JDK, to be later opened as a public API. The JEP has been returned to draft due to permanent feeling of incompleteness of the Classfile API and for lack of real cases and real impact on the JDK.
On the other side it is vital for Classfile API to grow on real cases and very specific applications across the whole JDK. The places of impact are tracked under [JDK-8294957](https://bugs.openjdk.org/browse/JDK-8294957) **Consolidate JDK class files parsing, generating, and transforming (umbrella)**, where 11 of the 18 umbrella sub-tasks (representing individual JDK integrations) have been experimentally implemented and 10 of them are tracked and manually re-based and synchronised in the jdk-sandbox repository branch.
It is a complex chicken and egg task to develop library designed to replace ASM (currently sitting in java.base), and at the same time to develop and test its integrations spread across the whole JDK (from java.base lambdas and method handlers generation to the last tier test). And at the same time to prove it is complete enough to have a right to sit in the java.base.
Classfile API is not classified as a standalone JDK project, as all the applications across JDK can be integrated independently. However it is critical for the Classfile API to evolve close to the JDK mainline, so it can became an integral part of other JDK projects (for example project Valhalla).
In this situation raised an idea to use GitHub pull requests chaining as a technical solution.
The idea is that many of the future applications of the Classfile API (the "chickens") can be individually reviewed, discussed and synchronised on top of this pull request (the "egg"), without immediate integration.
BTW: Originally I though it will be enough to keep this pull request as draft, however technical limitations did not allow me to chain another pull request to a draft pull request.
Any suggestions or proposals are welcome.
Thanks,
Adam
-------------
PR: https://git.openjdk.org/jdk/pull/10982
More information about the build-dev
mailing list