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