<i18n dev> RFR: JDK-8285932 Implementation of JEP-430 String Templates (Preview) [v17]

[Jorn Vernee]

On Thu, 10 Nov 2022 17:42:04 GMT, Jim Laskey <jlaskey at 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:
> 
>   Requested changes #5

src/java.base/share/classes/java/lang/template/Carriers.java line 415:

> 413:          */
> 414:         @Stable
> 415:         private final Object[] objects;

Looking at all this, I'm skeptical that carriers are worth the complexity for the performance gain they give. AFAICS the fast paths for `FMT` and `STR` avoid boxing values into a StringTemplate instance altogether. So carriers only seem to help cases where processing goes through the default `process` method on a user-defined processor?

AFAIK `@Stable` will not do anything here. It only helps constant folding from a constant root object and in general StringTemplate instances are not constant. (and, AFAIK there are also JIT caveats with storing everything in arrays like this).

I suggest maybe keeping things simple in this PR, and having a `StringTemplateImpl` with just a `List<Object>` for the values. Public support for the linkage-based fast path can be used to avoid the boxing for user defined processors in the future as well, and that seems like a much better way to get performance to me.

If carriers are added to improve performance, I'd personally like to see that in a separate PR that's only focused on that, with more benchmarks/bench marking results included as well.

-------------

PR: https://git.openjdk.org/jdk/pull/10889