Update on String Templates (JEP 459)

[Maurizio Cimadamore]

Hi Tagir,
while subclassing is handy, I think it actively works against the goal 
of trying to make string handling any safer.

Let’s consider the case of a /new/ API, that wants to do things the 
/right/ way. This API will provide a StringTemplate-accepting factory.

But if clients can supply a value using |"foo" + bar|, then we’re back 
to where we started: the new API is no safer than a String-accepting 
factory.

Note: there is a big difference between passing |"foo" + bar| and 
|"foo\{bar}"|. In the former, the library only gets a string. It has no 
way to distinguish between which values were user-provided, and which 
ones were constant. In the latter, the string template has a value. The 
library might need to analyze that value more carefully as it might come 
from outside.

The main value of string templates is to allow clients to capture what 
/can change/ and separate it from what /cannot/ change. Attacks 
typically lurk in the variable part. But eager interpolation (e.g. 
string +) destroys this separation.

> I think that most of the APIs will still provide String overload. 
> E.g., for preparing an SQL statement, it's a perfectly reasonable 
> scenario to have a constant string as the input. So 
> prepareStatement(String) will stay along with 
> prepareStatement(StringTemplate). And people will still be able to use 
> concatenation. I don't think that the absence of String <: 
> StringTemplate relation will protect anybody from using the 
> concatenation. On the other hand, if String actually implements 
> StringTemplate, it will be a very simple static analysis rule to warn 
> if the concatenation occurs in this context. If the expected type for 
> concatenation is StringTemplate, then something is definitely wrong. 
> Without 'String implements StringTemplate', one will not be able to 
> write a concatenation directly in StringTemplate context. Instead, 
> String-accepting overload will be used, and the expected type will be 
> String, so static analyzer will have to guess whether it's dangerous 
> to use the concatenation here. In short, I think that it's actually an 
> advantage: we have an additional hint here that concatenation is 
> undesired. Even compilation warning could be possible to implement.
>
> So, I don't see these points as real disadvantages. I definitely like 
> this approach much more than adding any kind of implicit conversion or 
> another literal syntax, which would complicate the specification much 
> more.

I don’t buy that, since there’s already String-accepting API in the 
wild, then we can never be safer than that. String-accepting variant can 
be deprecated, if needs be.

Maurizio

​
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-spec-experts/attachments/20240313/32b1006b/attachment.htm>