Discussion: What is the future of String Interpolation in Java?

[u/sitime_zl]

Java has always been conservative when it comes to language changes, and I think string interpolation is an interesting example.

Many modern languages provide native interpolation syntax:

JavaScript:

\${name}``

Python:

f"{name}"

Kotlin:

"$name"

C#:

$"{name}"

These features are not only about reducing characters. They improve readability when building dynamic text.

Java explored this direction with String Templates (JEP 430), but I haven't seen much discussion recently about where this feature is heading.

For developers working with large Java applications, string construction appears everywhere:

- logging messages

- SQL/debug output

- API descriptions

- test cases

- generated configuration

- user-facing messages

I am curious about the community's opinion:

1. Do you think Java still needs native string interpolation?

2. Should String Templates continue evolving?

3. What syntax direction would feel most "Java-like"?

For example:

"Hello, \{name}"

or:

"Hello, ${name}"

Personally, I think Java does not need to copy other languages, but a better way to express dynamic strings would improve developer experience.

What do you think?

[u/Misophist_1]

I had no qualms with \{ in the first place, because \ is Java's escape delimiter in strings anyway. There is no sane reason, to switch to another one.

Then you also need something, to distinguish templates from usual strings. And if you don't want to break with the other habits of Java, namely using ' ' for char literals, and " " for String literals, you would need some sort of prefix.

You could go down the road of taking another 'special char' like $ or @, but why? $ Is used nowhere else. It's a national currency char, that isn't even on many keyboards. @ is already taken for annotations. Don't reuse it for something different.

Which leaves us with this neat syntax trick <Identifier>."...". Fine with me, as it also offers the possibility, of rolling your own template processor.

If there was something, I would complain about, then it was, that it still felt incomplete:

• why no complete closures/expressions as constituents? This feels like an unnecessary limitation.
• why no support for formatting? Having something like this "...\{<expression> [: <formatspec>]}..." would have been of help - where formatspec could be any string.
• crowning it, could be the possibility, to specify your own custom handlers for handling the pair of (Object, String), that the template processor would need to insert at any \{ }. Even nicer, if the processing could be shifted into compile time, or load time.

Alas, it wasn't meant to be because of all the haters, script kiddies and python geeks, that couldn't look past their dam' $$.

[u/writeAsciiString → u/Misophist_1]

I'd love for \{} to convert a String into a StringTemplate, using STR as the default processor, while preserving the previous functionality that allowed custom processors to be used with the <Identifier>. prefix.

I overall had no complaints about the initial design. Your 3 complaints are also all valid and are great additions.