A bit late to the party, but yes. Although, in true Java form the designers sacrificed readability to satisfy lesser use-cases.

STR.”Total: \{count}”

Could not get uglier.

I haven't tried it yet but I'm guessing this will fold into a different visual representation in IntelliJ when the cursor isn't nearby. It's not pretty but if it's consistent I guess it's fine.

I’m using project manifold’s string templates[1] and loving it.

1. https://github.com/manifold-systems/manifold/tree/master/man...

> I haven't tried it yet but I'm guessing this will fold into a different visual representation in IntelliJ when the cursor isn't nearby.

sigh

Eww, you're not kidding, that's awful.

Java is my most ambivalent language. There's things I love, and things I hate, and when it's good it's really good, when it's bad ... Yuck.

That said, I do think Python went worse with f-strings. Would have loved to see Java look to Groovy for inspiration.

It looks so bad in the context they give themselves:

C# $"{x} plus {y} equals {x + y}"

Visual Basic $"{x} plus {y} equals {x + y}"

Python f"{x} plus {y} equals {x + y}"

Scala s"$x plus $y equals ${x + y}"

Groovy "$x plus $y equals ${x + y}"

Kotlin "$x plus $y equals ${x + y}"

JavaScript `${x} plus ${y} equals ${x + y}`

Ruby "#{x} plus #{y} equals #{x + y}"

Swift "\(x) plus \(y) equals \(x + y)"

And finally:

Java STR."\{x} plus \{y} equals \{x + y}"

It's explained if you look at the proposals: They wanted to avoid any and all risks of backwards compatibility with any existing templating tool in the Java ecosystem. Every sensible syntax was covered by one of those, so the core language is stuck with the least bad one available.

It's prefixed by "STR." so the syntax is different from any existing tools ?

It remember me the first proposed syntax for lambdas. Let's hope the next preview will fix that.

...at what cost tho

The JEP makes it kind of clear:

> trading off a small amount of convenience to gain a large amount of safety

*large

*small

You can create json and sql string template processors that suffer from no injection problems. I'd call that a large improvement over, for example, Javascript. But I'm not familiar enough with the string template feature in the other languages to comment on their relative security.

> You can create json and sql string template processors that suffer from no injection problems. I'd call that a large improvement over, for example, Javascript.

Bad example. JavaScript literally has that. [1]

  function sql(strings, ...args) {
    // ...
  }

  sql`SELECT * FROM user WHERE email = $1`

[1] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

This is a solved problem in .NET, and C# only has one kind of string templating:

  FormattableString foo = $"select * from {table} where {column} = 42";

https://learn.microsoft.com/en-us/ef/core/querying/sql-queri...

Not sure if C# can do that, but java’s implementation can return an arbitrary object based on the templates/parameters.

As a reminder, you still can make it $.”…” in your code, if you wish.

It makes perfect sense if you consider that String Templates don't just support interpolation, but also /escaping/ of values. Therefore, Java's existing syntax for escaping stuff is the obvious choice for consistency reasons. If interpolation is all you want, use `STR`. In the future, we will see libraries with template processors for regex patterns, SQL, XML, etc.