On Wed, 2 Nov 2022 19:44:00 GMT, Jim Laskey <jlas...@openjdk.org> wrote:
>> Enhance the Java programming language with string templates, which are >> similar to string literals but contain embedded expressions. A string >> template is interpreted at run time by replacing each expression with the >> result of evaluating that expression, possibly after further validation and >> transformation. This is a [preview language feature and >> API](http://openjdk.java.net/jeps/12). > > 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? ------------- PR: https://git.openjdk.org/jdk/pull/10889
