String templates
Ron Pressler
ron.pressler at oracle.com
Thu Aug 7 19:53:21 UTC 2025
> On 25 Jul 2025, at 20:53, Archie Cobbs <archie.cobbs at gmail.com> wrote:
>
> On Thu, Jul 24, 2025 at 9:16 PM Rob Ross <rob.ross at gmail.com> wrote:
> First, I welcome suggestions and feedback on what kind of information is useful to contribute to the topic of string templates in Java.
>
> There was some preliminary work on this but it got shelved for various reasons.
>
> I hope Brian will let me know if the following comments are out-of-scope... :)
>
> My own current thinking on this topic is that instead of trying to define the one true template syntax, Java should take a "pluggable syntax" approach to this problem.
>
> This would be roughly analogous to annotation processing: The compiler calls out to plug-ins (implementations of SyntaxProcessor say) to evaluate chunks of source code ("templates").
>
> The plug-ins would in turn convert the templates into "recipes" for normal evaluation and pass them back to the compiler. Exactly what these "recipes" are is TBD.
>
> This would look similar to JEP 465 but would be fully agnostic about (a) the literals that define the templates and (b) how they are interpreted.
>
> Simple example equivalent to JEP 465 but with a different (better?) interpolation syntax:
>
> import com.example.syntax.SQL;
>
> public class MyClass {
>
> public PreparedStatement buildSQL(String name, int age) {
> return SQL."SELECT * FROM Person WHERE name = :name AND age = :age";
> }
> }
>
> Key points...
> • The syntax for, and meaning of, "interpolation" in the template, if any, is determined entirely by the SyntaxProcessor.
> • The Java type of the evaluated template expression can be any Java type (ideally, determined dynamically by the SyntaxProcessor)
> • The Literal does not have to be a String, it could be any Java literal. Examples: Currency.'€', Year.2025, etc.
> • The SyntaxProcessor can "access" arbitrary Java expressions, i.e., it can pass them back to the compiler for (eventual) evaluation as part of the "recipe". This facilitates interpolation.
>
> Another simple example demonstrating a totally different "interpolation" that's more appropriate for an XSL transform:
>
> import com.example.xml.XSLT;
> import javax.xml.transform.*;
>
> public class MyClass {
>
> public void xmlSplitFullName(Source input, Result output, String fullNameTag) {
> XSLT."""
> <xsl:transform xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="2.0">
>
> <xsl:param name="fullNameTag"/> <!-- "interpolation" happens here... -->
>
> <xsl:template match="Person/*[name(.) = $fullNameTag]"> <!-- ...NOT here -->
> <lastName>
> <xsl:value-of select="substring-before(., ', ')"/>
> <lastName>
> <firstName>
> <xsl:value-of select="substring-after(., ', ')"/>
> <firstName>
> </xsl:template>
>
> <xsl:template match="@*|node()">
> <xsl:copy>
> <xsl:apply-templates select="@*|node()"/>
> </xsl:copy>
> </xsl:template>
>
> </xsl:transform>""".transform(input, output);
> }
> }
>
> -Archie
>
> --
> Archie L. Cobbs
I think that if we look at the marginal cost and the marginal benefit of this compared to a uniform template argument syntax, the result is unappealing.
On the cost side, we’re talking about running arbitrrary third-party code at compile time (including IDE-editing time), which brings some challenges, not to mention that simple syntax highlighting in web interfaces like GitHub simply won’t work.
Furthermore, this could only reliably work when the template is a complete document in the target language, which is often not the case. For example, the text `name = “fullNameTag”` in HTML/XML could be either an element attribute assignment or (part of?) a text node, depending on the context in which it appears. Partial templates are often useful, but if even determining whether something is an argument or or a fragment is programmable, partial templates become effectively impossible.
On the benefit side we gain, what? The ability to copy-paste templates from existing templating engines without any processing?
— Ron
More information about the amber-dev
mailing list