Update on String Templates (JEP 459)

[Clement Cherlin]

On Tue, Mar 19, 2024 at 2:13 PM Guy Steele <guy.steele at oracle.com> wrote:

> On general principle, I would agree about instance methods often being
> better than static methods for various reasons, other things being equal.
>
> But in this specific discussion we have heard concerns about confusing
> templates with string interpolation. When it comes to safety of (say) SQL
> processing, which of the following would we prefer:
>
> SQL($"SELECT * FROM \{tableName} blah blah blah”.xyzpdq());
>
> SQL(xyzpdq($"SELECT * FROM \{tableName} blah blah blah”));
>
> The first one avoids nested parentheses. The second one says right up
> front, “Danger, Will Robinson, danger! The template will not be processed
> in the way you might think!"
>

If xyzpdq() is STR/interpolate/join, and SQL() only accepts StringTemplate
(as it should), then either one will fail to compile.

I am increasingly convinced that the right framing of String vs
StringTemplate is not a family relationship, like String vs CharSequence,
but an arms-length relationship like String vs byte[]. I would extremely
rarely write two same-named overloads, one accepting byte[] and the other
String.

While String and StringTemplate (and byte[]) are strongly related, and you
can readily create any one from any other, they serve distinct purposes and
have very different security properties. Like byte[], a StringTemplate can
contain mutable data, and also like byte[], you need additional context to
safely and correctly process one into a String or other object. Unlike both
byte[], and String, a StringTemplate contains arbitrary objects with
arbitrary behaviors, which gives StringTemplate a completely different
threat model.

For all of these reasons, I would extremely rarely write same-named
overloads, one accepting String and the other StringTemplate. A client
having to deal with a compiler error if they call the wrong one is a
feature.

I think the release notes and documentation for StringTemplate should
explicitly recommend different names for methods accepting String vs.
StringTemplate, rather than same-name overloads, for both safety and
clarity.

Cheers,
Clement Cherlin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-spec-observers/attachments/20240319/30512ac4/attachment-0001.htm>