RFR: 8294982: Implementation of Classfile API [v36]

[Paul Sandoz]

On Mon, 6 Mar 2023 17:02:46 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/classfile/CodeBuilder.java line 165:
>> 
>>> 163:      * @return this builder
>>> 164:      */
>>> 165:     default CodeBuilder transforming(CodeTransform transform, Consumer<CodeBuilder> handler) {
>> 
>> The functionality of this method, `transforming`, and `ClassfileBuilder::transform`, are in effect equivalent in their transforming: adding the results of transformed code to the builder. They differ in the source of code elements.
>> 
>> The latter's behaviour can be implemented using the former, with a  consumer that passes all elements of a code model to the builder e.g. `builder -> model.forEach(builder::with)`.
>> 
>> The difference in naming initially confused me. To me this suggests the method names should be the same? (perhaps with the transformer being consistently the last argument?).
>
> The `CodeBuilder::transforming` solves a bit different use cases than all the other transform.
> It is designed to be able to use code transformations on a code building handler within a single pass.
> Main reason is support of features like `StackTracker` in a form of code transformation. `StackTracker` (or any other similar tool requiring to monitor or affect code building) is passed as a transformation of a code fragment, while it can immediately serve as a source of information necessary to generate follow-up bytecode of the same method (in the same pass). 
> Example of such use case is here: 
> https://github.com/openjdk/jdk/blob/0e43af667ba6c6bda61461c260688bc46d3f3474/src/java.base/share/classes/jdk/internal/classfile/components/CodeStackTracker.java#L49
> 
> These code generation/transformation cases must be handled in a single pass and `CodeBuilder::transforming` method has no similar peer in any other (method, field or class) builder, because it is not necessary.

The use-case seems fine to me (and that it only makes sense for building code). I still think it's a "transform", but with a different source. Subtly changing the name makes it seem different and fundamentally it is not AFAICT. If there is a separate name I think it should reflect the difference in source input to the transformation, rather than differentiate via the present participle.

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

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