RFR: JDK-8285932 Implementation of JEP-430 String Templates (Preview) [v11]

[Rémi Forax]

On Wed, 2 Nov 2022 21:53:00 GMT, Jorn Vernee <jvernee at 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