RFR: 8294982: Implementation of Classfile API [v36]

[Adam Sotona]

On Mon, 6 Mar 2023 17:15:25 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> 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.

I see what you mean. `transforming` was selected to represent the continuation of the code building process, similar to `trying` and `catching`. While `transform` may imply that the actual code builder gets transformed into something else. For example `MethodModel::transformCode` takes `CodeModel`, applies `CodeTransform` and after that the code of the actual method is finished.
What about `transformBlock(BlockCodeBuilder, CodeTransform)`?

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

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