RFR: 8294982: Implementation of Classfile API [v43]
Paul Sandoz
psandoz at openjdk.org
Fri Mar 3 23:49:46 UTC 2023
On Fri, 3 Mar 2023 16:39:41 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 three additional commits since the last revision:
>
> - fixed AccessFlags javadoc
> - TransformImpl.FakeXyzTransform renamed to UnresolvedXyzTransform
> - removed obsolete generic parameter from AbstractDirectBuilder
This is a significant amount of work over a long period of time. Well done to all involved.
Initially it's easy to get overwhelmed with the quantity of new classes. There are lots of "things" in a classfile and to properly model a classfile there will naturally be lots of classes for those "things". It's all very logically structured and very disciplined.
For me the most powerful aspect of the design is that of the builder, which can be combined with a flatmap transformation and pattern matching. A clean, functional, and immutable design. When transforming a classfile the developer has a choice to apply composed transformations to a stream of elements or obtain a list of all elements and apply more globally (perhaps building up a transformation plan that is then applied to the stream), depending on their needs.
It's slightly awkward that composed transformers (resulting from `andThen` and `ofStateful`) cannot be operated on and the resolved artifact is exposed, but i don't think anyone will likely notice given the usage. (I cannot off the top of my head suggest anything better. Maybe as this soaks internally new ideas emerge.)
-------------
Marked as reviewed by psandoz (Reviewer).
PR: https://git.openjdk.org/jdk/pull/10982
More information about the build-dev
mailing list