JEP draft: String Templates (Final)

Original Article ↗ Hacker News Discussion ↗

Java’s new String Templates proposal for the language core is drawing both praise for its security-focused design and criticism for its unusual, verbose syntax (`STR."...\{x}..."`). Supporters argue that template processors and the `\{}` syntax enable safer construction of SQL, HTML, JSON, and other structured outputs by steering developers away from raw string interpolation and injection risks. Critics counter that the feature overcomplicates a problem other languages solve with simpler interpolation, questioning whether the ergonomics trade-offs and backward-compatibility justifications are worth the added complexity.

Overall reception

  • Many welcome finally having string templates in Java and see them as powerful, especially with custom processors and type-safe APIs (HTML, SQL, JSON).
  • A substantial portion of comments find the design “ugly”, “over‑engineered”, and too verbose compared to other languages (Kotlin, Python, JS, C#, etc.).
  • Some argue that, despite the design rationale, the common case (simple interpolation) is now worse than in other languages and than existing Java idioms.

Syntax: STR."..." and \{...}

  • Strong criticism of the STR. receiver plus \{expr} syntax: visually noisy, confusing because \ is traditionally an escape, and easy to misread as escaping { rather than starting interpolation.
  • Others defend it as consistent with Java: \ already means “special interpretation in a literal”; \{ was previously illegal, enabling helpful compile‑time errors when a processor is omitted.
  • Some argue that since a processor like STR is required anyway, using \{} for backward compatibility is redundant; ${} or {} could have been used instead.
  • Counter‑argument: $ is widely used in existing Java templating ecosystems, and making it special would force escaping and migration pain.

Security and design goals

  • Proponents emphasize that the feature is not meant to be mere string interpolation; it is designed to combat injection vulnerabilities by:
    • Making template expressions method calls on typed processors (e.g., SQL."...", HTML."...").
    • Allowing libraries to refuse plain String APIs and accept only safe, processor‑produced types.
  • Critics respond that in practice most developers will just use STR/FMT for interpolation and keep writing unsafe SQL/HTML as strings.

Custom template processors / DSLs

  • Some see user‑defined processors as a major win, akin to JavaScript tagged templates and Scala interpolators, enabling safe, domain‑specific builders (SQL, HTML, JSON, XML).
  • Others fear proliferation of ad‑hoc mini‑DSLs, increasing cognitive load and maintenance risk.
  • A few note that similar features in Scala and JS have not obviously led to widespread abuse.

Performance and tooling

  • Concerns raised about allocation overhead (lists of values) and dependence on MethodHandle specialization; replies note that specialization isn’t limited to built‑in processors.
  • Some argue that the claimed “no extra tooling cost” is overstated, since parsers/IDEs still must handle new expression forms.