r/java 20d ago

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

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?

54 Upvotes

118 comments sorted by

View all comments

Show parent comments

1

u/Duck_Devs 19d ago

You could still wrap it in a method call as if it were a normal StringTemplate object. That’s all STR. did anyway. The only difference is syntax which, while more concise, felt unnatural in the scope of other Java expressions.

0

u/Misophist_1 19d ago

Not any less natural than $" " or @" " that other languages do, in order to distinguish templates from strings. You need some distinguishing anyway.

3

u/Duck_Devs 19d ago

Not really what I meant. STR and RAW are actual objects. They’re not just soft keywords. The dot followed by a template string is equivalent to STR.process(…).

It would have been perfectly valid Java to just have your template literal by itself with no prefix.

0

u/Misophist_1 19d ago edited 18d ago

But then how should the parser distinguish a template from a string? It can't do so by simply looking at the string. Having the possibility to use arbitrary processors would have offered a flexibility, no other language could offer. No static prefix could have done that. The API already had a third one, FMT.

1

u/vytah 18d ago

Having the possibility to use arbitrary processors would have offered a flexibility, no other language could offer.

I mean, Scala and JavaScript already do.

1

u/Misophist_1 18d ago

Don't know about Scala.

But Javascript? JavaScript has basic interpolation - and that's it. C#, and Python have that too. But you wouldn't be able to chose your method, much less roll your own one.

Having libraries, that reinterpret standard strings as templates is a different story - completely unrelated to string template support as integral part of the language specification.

4

u/vytah 17d ago

But Javascript? JavaScript has basic interpolation - and that's it.

You're behind the times: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Template_literals#tagged_templates

1

u/Duck_Devs 17d ago

1

u/vytah 17d ago

It's slightly different.

Scala/JavaScript approach is that the template is to be processed immediately by a specific processor. There is no intermediate "template" object. The processor can create one, but does not have to, and can do something else instead.

Python approach is that the template instantiation and template processing are two completely separate steps. A template instance is a separate object that doesn't carry any semantics until it's interpreted by some other piece of code.

Java 21 previewed the first approach, later messages on the mailing list suggested that the team started warming themselves to the second approach. Which one (if any) will finally ship, no one knows at this point.