On Mon, 6 Mar 2023 17:02:46 GMT, Adam Sotona <asot...@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

Reply via email to