On Fri, 4 Nov 2022 12:38:04 GMT, Adam Sotona <asot...@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

Reply via email to