On Wed, 2 Nov 2022 21:53:00 GMT, Jorn Vernee <jver...@openjdk.org> wrote:
>> 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) Yes, the current code only supports processors with no fields, which is Okay given that the interface `ProcessorLinkage` is sealed. If/When the processor linkage API is open for everyone as you said the design will have to be changed. But going the other way, creates a general mechanism is painful because either you have an adhoc way to associate the processor to a BSM-like method or you have to delay until runtime the linkage using a monomorphic/polymorphic cache (I know Jim has tested that before back-pedaling to a simpler more constrained good enough solution). ------------- PR: https://git.openjdk.org/jdk/pull/10889
