Java string interpolation feature has been cancelled

Status of the feature

• The change is the removal of String Templates from the JDK 23 preview, not a permanent cancellation.
• Several commenters call the HN title misleading; the feature is still being redesigned and is expected to return in a later release.
• Contrast is drawn with Go generics: here the feature wasn’t repeatedly rejected, but pulled once a late design flaw was found.

Technical reasoning and new direction

• Real-world use (notably in an internal project) revealed fundamental flaws in the “template processor” model.
• The team now favors “StringTemplate literals” without an explicit processor abstraction.
• New direction: StringTemplates remain distinct from plain Strings to preserve security properties and allow sensitive APIs to treat them specially.
• This likely shifts responsibility to libraries to add overloads that accept StringTemplates directly.

Security and API design concerns

• Interpolation is seen as a major source of vulnerabilities (e.g., SQL injection).
• A type-safe template model can allow validation and constraints that concatenation cannot, especially for domain-specific outputs.
• Example discussed: a db.query(STR."...")-style API where templates are accepted safely, but raw Strings are discouraged or deprecated.
• Some worry about “automatic conversion” from strings to templates being confusing or unsafe; preferences lean toward explicitness.

Syntax debates and community feedback

• Lots of public feedback focused on syntax details (e.g., backslash vs dollar), often seen as emotional and unhelpful.
• Language designers characterize this as “anti-helpful” bikeshedding that buried more substantive feedback.
• Nevertheless, the ultimate rollback is attributed to deeper model flaws, not syntax complaints.

Comparisons with other languages

• JavaScript and C# are cited as having well-established models (template literals, interpolated strings, tagged templates, custom handlers).
• Scala/Kotlin-style simple interpolation is suggested as an 80% solution that Java rejected as “not ambitious enough.”
• Some speculate Java overreached by trying to “solve” SQL/XML/JSON generation in the core feature instead of leaving it to libraries.

Templating vs. built-in language features

• Some argue server-side interpolation is essential and should be as ergonomic as in other ecosystems.
• Others say HTML/SQL templating is already well covered by libraries (e.g., JSP, JTE, kotlinx.html) and doesn’t need core language support.
• There’s debate over whether embedding control flow and expressions in templates belongs in separate template languages or directly in Java.

Java vs. Kotlin and broader language design

• Thread drifts into “why use Java over Kotlin” debates: Kotlin seen as nicer syntactically, with null safety and property syntax; Java defenders point to records, immutability, and adequate modern ergonomics.
• Some feel Java syntax evolution (raw strings, templates) has become overly complex and “C++-like,” others report enjoying “modern Java” as-is.