On Wed, 2 Nov 2022 21:30:23 GMT, Jorn Vernee <jver...@openjdk.org> wrote:
>> Jim Laskey has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Internalize TemplateSupport > > src/java.base/share/classes/jdk/internal/template/TemplateSupport.java line > 147: > >> 145: >> 146: return support.processWithProcessor(); >> 147: } > > Thinking about this protocol some more: this seems to depend on the processor > being a constant, which precludes specialized linking of call sites where the > processor is a dynamic argument. > > The returned method handle/call site could maybe be changed to take the > processor instance as a leading argument instead. The processor can then be > used to pass additional arguments to the processing code (like the DB example > in the JEP). (and, AFAICS, that will also allow using calls to this BSM as > the sole translation strategy for every type of processor, which seems more > robust if types are changed later on to (un-)implement `ProcessorLinkage`) > > The `linkage` method could instead be a `static` method, which is somehow > tied to the type of the processor. Since it's currently a sealed interface > you could have a mapping from each implementer to the `linkage` method for > the types you care about (only `FormatProcessor` atm). If that is to be > opened up to public extension in the future, something like type classes > would be needed I think, so that the runtime can reliably map from the > processor type to the static `linkage` method. > > WDYT? (FWIW, I don't see this as prohibitive for this PR to go ahead, but maybe something to consider before finalizing the feature) ------------- PR: https://git.openjdk.org/jdk/pull/10889
