On Mon, 6 Mar 2023 17:02:46 GMT, Adam Sotona <[email protected]> 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
