JDK-8318909 : JEP 459: JLS Changes for String Templates (Second Preview)
  • Type: CSR
  • Component: specification
  • Sub-Component: language
  • Priority: P4
  • Status: Closed
  • Resolution: Approved
  • Fix Versions: 22
  • Submitted: 2023-10-26
  • Updated: 2024-04-12
  • Resolved: 2023-11-14
Related Reports
CSR :  
Duplicate :  
Relates :  
Relates :  
Relates :  
Description
This is the CSR for the Java Language Specification changes of [JEP 459 String Templates (Second Preview)](https://bugs.openjdk.org/browse/JDK-8314219)

Summary
-------

Enhance the Java programming language with _string templates_. String templates complement Java's existing string literals and text blocks by coupling literal text with embedded expressions and processors to produce specialized results.  This is a [preview language feature and API](http://openjdk.java.net/jeps/12).

Problem
-------

Developers routinely compose strings from a combination of literal text and expressions. Java provides several mechanisms for string composition, though unfortunately all have drawbacks.

- String concatenation with the `+` produces hard-to-read code:

        String s = x + " plus " + y + " equals " + (x + y);

- `StringBuilder` is verbose:

        String s = new StringBuilder()
                     .append(x)
                     .append(" plus ")
                     .append(y)
                     .append(" equals ")
                     .append(x + y)
                     .toString();

- `String::format` and `String::formatted` separate the format string from the parameters, inviting arity and type mismatches:

        String s = String.format("%2$d plus %1$d equals %3$d", x, y, x + y);
        String t = "%2$d plus %1$d equals %3$d".formatted(x, y, x + y);

- `java.text.MessageFormat` requires too much ceremony and uses an unfamiliar syntax in the format string:

        MessageFormat mf = new MessageFormat("{0} plus {1} equals {2}");
        String s = mf.format(x, y, x + y);

The convenience of interpolation also has a downside: It is easy to construct strings that will be interpreted by other systems but which are dangerously incorrect in those systems.

Strings that hold SQL statements, HTML/XML documents, JSON snippets, shell scripts, and natural-language text all need to be validated and sanitized according to domain-specific rules. Since the Java programming language cannot possibly enforce all such rules, it is up to developers using interpolation to validate and sanitize. Typically, this means remembering to wrap embedded expressions in calls to `escape` or `validate` methods, and relying on IDEs or [static analysis tools](https://checkerframework.org/manual/) to help to validate the literal text.

Interpolation is especially dangerous for SQL statements because it can lead to [injection attacks](https://en.wikipedia.org/wiki/SQL_injection). The prevalence of injection attacks as led to organizations dedicated to preventative measures, ex., [OWASP][https://en.wikipedia.org/wiki/OWASP].

Solution
--------

[JEP 459 String Templates (Second Preview)](https://bugs.openjdk.org/browse/JDK-8314219) introduces _string templates_ which will allow users to inject values into a String in situ. The use of string templates versus string interpolation allows for a richer feature that, in addition to composition, allows validation and non-string result transformations.

For the purposes of a terminology overview, the statement;

```
    String s = x + " plus " + y + " equals " + (x + y);
```

can be equivalently expressed using the _template expression_;

```
    String s = STR."\{x} plus \{y} equals \{x + y}";
```

The template expression is composed of two parts, the _template processor_ and the _template argument_ separated with a dot.

The template processor is an expression that when evaluated produces an instance of a class implementing the `ValidatingProcessor` interface. This _processor instance_ receives the details of the template argument by way of the processor's `process` method. The processor uses this method to validate the details of the argument and then produce a result. It is through this `process` method that the string templates feature provides a more secure and richer mechanism than string interpolation.

The automatically imported `STR` template processor used in the example, provides the equivalence of string interpolation.

The template argument can be a string literal, a text block or a _template_. A template has the appearance of a string literal or text block, except the literal's content incorporates one or more _embedded expressions_  distinguished from the literal parts of the content by bracketing with `\{ `and `}`. An embedded expression can be any Java expression.

Once the template argument and embedded expressions are evaluated, the details of the template argument are incorporated into an instance of class that implements the `StringTemplate` interface. The details are represented using two lists, a list of string _fragments_ - the characters outside of the embedded expressions and a list of _values_ - the results of evaluating the embedded expressions.

The template argument details for the example would be a fragments list equivalent to `List.of("", " plus ", " equals ", "")` and values list equivalent to `List.of(x, y, x + y)`. Note that all fragments are provided even if empty.

Further details can be found in the JEP [JEP 459 String Templates (Second Preview)](https://bugs.openjdk.org/browse/JDK-8314219) and the enclosed Java Language Specification edits.

Specification
-------------

Details of the Java Language Specification edits are enclosed.

Changes described above are only available with `--enable-preview`. No class file changes are required.

Comments
Moving CSR with the corrected spec to Approved.
14-11-2023

[~darcy] Corrected spec uploaded
14-11-2023

[~gbierman], is this still the latest proposal or does it need to be updated for the the set of template processors auto-imported?
14-11-2023

Moving to Provisional.
31-10-2023

[~darcy]: Yes, there are two changes (both are listed in the history prelude of the spec doc): 1. (15.8.6) A change to the typing of template expressions to use the return type of the corresponding process method. 2. (13.1) Removed requirement that references to fields always be compiled into symbolic references, adding an exception for references to imported members of StringTemplate. (This allows for compilers to optimize template expressions where the template processor is STR or RAW such that the interface StringTemplate may not even be loaded and initialized.)
26-10-2023

[~gbierman], can you summarize what changes, if any, are made compared to the first preview?
26-10-2023