var $ = STR;
    var $h = new HtmlTemplateThing();
    var $j = new JSONTemplateThing();

    var name = "John";

    var s = $."Hello \{name}";
    // HTML escaped
    var h = $h."<b>\{name}</b>";
    // JSON escaped
    var j = $j."""
        { "name" : "\{name}" }
    """;  // JSON escaped

    var $db = new DBConnectionTemplateThing();

    // SQL Escaped and processed
    PreparedStatement st = $db."select * from table where name = '\{name}'";
    

    var $x = new XMLTemplateThing();

    // XML escaped and parsed
    Document d = $x."<xml>\{name}</xml>";

Doesn't look that terrible to me.

https://developer.apple.com/documentation/swift/stringinterp...

It's the reason they didn't chose "${" like many other languages. Because that's a valid sequence in a string literal.

    var q = DB."SELECT foo FROM bar WHERE a = \{b}";   // PreparedStatement?
    var results = conn.execute(q);                     // ResultSet

That said, I wonder how often people are writing queries out by hand like that these days vs using ORMs or jOOQ.

Yes, we already have that problem solved with JPQL or even just plain prepared statement but that’s never stopped anyone…

And yes, you could also write a message formatter the current Java that does that…

    "..." + foo + "..." + bar + "..."

    STR."...\{foo}...\{bar}..."

    FOO."..."

> String interpolation is dangerous > Can we do better?

1. Introducing syntax for new kind of string literals (like JS did)

2. Make some kind of explicit function/constructor call (like they ended up doing).

Advantage of 2 is that it doesn't require any new support from IDEs/parsers/code quality tools/etc. It is slightly more verbose, but not as verbose as some other Java syntax. IMO they've made the right decision.

- no strange leading character(s) (per C#, VB, Python, Scala, and now Java)

- templated strings are actually distinguished, so don't have to worry about accidentally running into template literals in normal strings (unlike Groovy, Kotlin, Ruby)

- the distinguishing mark appears at the end as well as the beginning, for slightly better legibility.

- Swift is quite nice in that the backslash is already an escape character for normal strings, so no issue with accidental use, but {} would have been a better choice than () as the former are rarer in normal strings.

You can agree or disagree with the JEP's goal, but pointing out that the JEP manages to discourage the very thing that it sets out to discourage merely acknowledges that the goal is met.

Sort of. The specialisation happens for any user of MethodHandle.invokeExact, which is what those processors use (i.e. the compiler doesn't specifically know about STR and FMT), it's just that the MethodHandle API for template processors is not yet public. I expect it will be made public later on.

The existing ${it} syntax is tied to string on the output, so it can't be repurposed. The java approach on the other hand keeps the output generic, so that it would also keep the door open for similar not-string compatibilities in off-JVM kotlin implementations. Whereas the ${it} the syntax kotlin already has couldn't do that. An approach like changing its semantics to define something that isn't a string when it exists at a StringTemplate.Processor call site would be terrible I think, php-grade terrible. At least as long as they don't also introduce that formatter-dot-template syntax which I'd consider a pointless redundancy with what kotlin already has: formatter{template} is already possible, expect for a way to write a template literal that resolves to something other than string.

What I certainly wouldn't expect is anything reminiscent of "automatically imported into every Java source file".

It's certainly a very visible language and one often talked about, but if you look at Google trends for Java versus kotlin you're looking at about 10% of the adoption that Java has or less.