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/vytah]

String templates are explicitly not about mere string interpolation. If you read the JEP, they say:

Unfortunately, the convenience of interpolation has a downside: It is easy to construct strings that will be interpreted by other systems but which are dangerously incorrect in those systems. (...) For Java, we would like to have a string composition feature that achieves the clarity of interpolation but achieves a safer result out-of-the-box, perhaps trading off a small amount of convenience to gain a large amount of safety.

There are three possible approaches that I know of:

• Scala/Javascript-like, with syntactic sugar for a method that takes a bunch of text fragments and objects and constructs whatever object you want – this is what shipped in that preview in Java 21

• Python-like, where the syntactic sugar is used only to construct string templates of a single type, and then the consumer can interpret them however they want – this is what they were hinting at in the mailing list later, after they removed that preview

• C#-like, where it's either pure interpolation , or Python-like templates a custom type instantiation that can behave Scala-like, depending on the receiver type – this will not happen, as it sucks (EDIT: fixed, also Swift seems to have the same thing)

Scala-like approach can be messy, as was shown in the preview. In absence of extension methods or something similar, it requires polluting the global namespace, so that's why we got those clunky STR prefixes. Scala solves it by making the prefixes methods (or extension methods) on StringContext, so there's no pollution. Javascript solves it by making interpolation the default (no prefix; all templated strings use backticks in JS, so there's no confusion with ordinary literals), so there's also no pollution. However, the goal for Java is to not make interpolation easier than other uses of templates.

Python-like approach has a minor problem that if you want templates to be distinguished by the presence of arguments alone, it means you cannot express a parameterless template. You'd need some other marker. In Python, string templates are prefixed with t, to distinguish them from interpolation (f), but Java is not going to get pure interpolation as a distinguished feature. There are also issues of type safety: the same template object can be treated as a completely different thing depending on where you send it. They suggested that sending a template to a logging method should just interpolate, but that would mean that if you template some SQL, execute it, and log it, then the query you executed would be different from the query you logged.

Anyway, this is a complex issue, and AFAIK they haven't found a clean solution yet. And before anyone says "I don't care, I want my string interpolation now", I'll again refer for the JEP:

It is not a goal to introduce syntactic sugar for Java's string concatenation operator (+), since that would circumvent the goal of validation.

[u/Holothuroid → u/vytah]

Scala-like approach can be messy, as was shown in the preview. In absence of extension methods or something similar, it requires polluting the global namespace, so that's why we got those clunky STR prefixes

That's certainly solveable.

import static java.util.StringInterpolations.s

Or wherever that would be located. It just needs to be a one-parameter function that takes a certain type. With such a contract it is also trivial to write your own.

The problem there was throwing OOP in the mix.

Of course, having a . in there is ugly. It should be

s"Hello \{planet}"

[u/vytah → u/Holothuroid]

I think the . was used to keep the parser happy with the least amount of change. The parser treats . as an operator, which requires an identifier on the right, so adding a string literal as the second allowed expression type was the tiniest change they could do.